well… my advice is to use semantic versioning (http://semver.org).
in essence: - a package commit is just a commit. The number is a commit number (bah.. is a little more complicated because the commit info is author-number, but you got the idea). - metacello configurations work as distribution artifacts, so they should have an unique and unrepeatable number (unless you are using git and baselines, in which case it changes). So you should not change the old version. Instead, you should add a patch number. In your case: 2.1 will become: 2.1.1 and then you can move the #stable symbolic version to 2.1.1 Esteban On 08 Aug 2014, at 14:53, Esteban A. Maringolo <emaring...@gmail.com> wrote: > Hi, > > How do you manage released versions updates in Metacello? > > E.g. > > I have a version 2.1, with its spec with a dependency to 'PackageA.11.mcz'. > Later I find a bug which requires a new version of PackageA.11.mcz, > everything goes ok as in the development/bleedingEdge version, which doesn't > specify the file name, but how should I "backport" the change? > > What I am doing now is changing the version spec for '2.1' and updating the > reference to 'PackageA.11.mcz' to 'PackageA.12.mcz', but I'm afraid this > isn't the proper way of doing this. > > How do you manage this? > > In git I'd merge the commit in the 2.1 version branch, and then the CI that > depends on such branch would incorporate the change. > > Regards! > > Esteban A. Maringolo
