Francois, Regarding the mutability of Metacello configurations ... you are right that it is tempting, but one should never modify a version that has been marked as #released ... it is a convention. One of the appeals of git/github is that a git commit is immutable so all of the artifacts in a commit are guaranteed. Even with git, tags (the only real place to use a version string) are not immutable ... by convention you don't change tags. In the end there is no replacement for discipline... Dale ----- Original Message ----- | From: "Francois Stephany" <tulipe.moutarde@gmail.com> | To: pharo-project@lists.gforge.inria.fr | Sent: Monday, May 14, 2012 9:02:25 AM | Subject: Re: [Pharo-project] Semantic Versioning | | | > So if I fix | > a bug, and now Pharo 1.3 will have to load package.pharo13.3 and | > Squeak | > package.squeak43.5, I would declare 1.3.1 in my config with the new | > packages. Does that sound right? | | Yep, sounds right. | What if you only need the bug fix in the Pharo version and not the | Squeak one? The package becomes 1.3.1 in Squeak but is identical to | 1.3.0. No big deal I guess... | | My main concern at the moment is that a MetacelloConfig is always | modifiable. It is tempting to fix a version that is already | distributed | and thus confuse everyone. | | A release should maybe be a complete new entity (and not editable) | hosted somewhere else than in the code repository. The Fuel gsoc | would | probably help a lot for that. We can maybe imagine something à la | Ruby gems? | |