3 Dec
2009
3 Dec
'09
11:44 p.m.
Hi,
On 3 Dec 2009, at 23:12, Simon Denier wrote:
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."
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 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
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.