Hi,
On 3 Dec 2009, at 23:12, Simon Denier wrote:
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).
The problem is that if we rely on 2 commits we also have to manually enter the version of the subproject in the overall project. This is very error prone. This is because there is no clear way to know what is the current version of the sub-project.
I see two possibilities here: 1. Just take the lastStableVersion from each subproject. This would rely on the assumption that someone has created already a version. 2. Detect the current version of a subproject by comparing the version written in the configuration with the monticello working copy version.
Doru
- 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.
The first 3 steps you have to click in the contextual menu of the Configuration, then the last two follows the 'save packages'. But all are options in the menu http://code.google.com/p/metacello/wiki/MetacelloTools (5 out of 8 actions, good shooting)
-- Simon
-- www.tudorgirba.com
"Some battles are better lost than fought."