3 Dec
2009
3 Dec
'09
11:12 p.m.
On 3 déc. 2009, at 19:00, Stéphane Ducasse wrote:
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 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
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)? - 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.