On 3 déc. 2009, at 19:00, Stéphane Ducasse wrote:

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

Sounds good to me.

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
we have to do step that manually or this is a menu (publish all dirty package of that configuration)?

This is in the menu.

Now there is issue #3 which dates back from september and in which apparently, new packages are not saved this way, only dirty.

Also I dont know if this works with nested configurations (but perhaps it's less important, we can make two separate commits in this case, one for each project).

- 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).

For now it can be what we need and if we should do two commits this is ok.