3 Dec
2009
3 Dec
'09
10:52 p.m.
On 3 déc. 2009, at 13:34, Simon Denier wrote:
On 3 déc. 2009, at 13:02, Simon Denier wrote:
Let's take an example with the latest CAnalyzer.
So I saved my changes in a new version which I called:
dev131: spec
<version: '1.3.1' imports: #('1.3')>
spec for: #common do: [
spec author: 'simondenier'.
spec timestamp: '12/3/2009 18:01'.
spec blessing: #development.
spec
package: 'CAnalyzer' with: 'CAnalyzer-simondenier.166';
package: 'XML-Parser' with: 'XML-Parser-Alexandre_Bergel.19';
package: 'Pastell' with: 'Pastell-Alexandre_Bergel.17';
package: 'Filesystem' with: 'Filesystem-cwp.51'.].
As you can, it is blessed as development with a micro number (1.3.1)
So we can have three levels of release with Metacello:
- baseline for the architecture
- version for major and minor release, which can be stable, beta, or
the main trunk of development
- dev for micro release for developers, which we can see as branches,
and which serves as history of development as Stef wishes
I called it dev, but maybe branch is a better name. Also a different
blessing could be used, I dont know. Any idea?
Note that Metacello handles well the numbering of version at major,
minor, or micro level.
Now about the process itself:
- *update the configuration* so that you get other micro releases and
you dont override one by accident :)
- spawn new version from the minor or micro release you want to derive
- save packages
- you are prompted to update package methods, which means update your
new version method with the package info
- then you are prompted to save the configuration
It means that actually you need to do two commits: one for the
packages, one for the configuration. Maybe we could improve the
process and making the whole thing works seamlessly
(save new version: spawn new version (prompt for version) -> save
packages (prompt for comment) -> update version -> save configuration
(reuse earlier comment).
--
Simon
*About the Moose process*
I dont think the Pharo process and the Moose process compare.
The Pharo process is about integrating fixes from packages which
are supposed to do one and only one thing, and do it well and is
tested.
The Moose process is about developers making incremental changes to
the code base so that they can work and share it immediately. Which
means it can break other things.
Now I'm pretty sure I dont want a release every time someone
commits a package in Moose, because I'm pretty sure this someone
didn't run all the tests before committing. So making a release for
each new commit makes no sense for me. We dont integrate changes,
we just merge when there are some divergent branches. That's why we
are always working with the dev version and the 'default' is one
way to do it.
If we want historical data about Moose, I guess it's still possible
to retrieve all latest packages at a given date. It will not be
very different from what we used at this date.
Now about the *release* process for Moose: sure I would like that
there will be more releases. Now as Doru said, when we do a
release, we should do it for every sub projects and it's bit
difficult with the current tools.
- One way to do automatically it is to use the test server to at
least create a new version from the latest dev version and blessed
it as 'tested' if 100% tests passed or 'broken'
But I dont want such versions to pollute the manual versions, which
are supposed to be stronger. So something like create automatically
'testedVersionXXX' with tests or broken as possible blessing.
- Then we can do manual release from time to time (every two weeks,
every months?), which requires more work as we have to do it for
the different subprojects first, and blessed it as beta or stable.
What people can do if they work with the development version: they
can always save the current versions of packages if they feel happy
with it, in a 'devXXXSimWorkingOnIssue' method blessed as
development. This will be like a branch and he can always start from
here next time (this way, he is not offended by potential breaks in
latest dev). But he should take care that it also merges well with
the main trunk in the end, because that's from where we will make
stable release.