I know this is the proper way of doing it according to semantic versioning. I was afraid of populating the Metacello config with lots of #version21: #version211: #version212, etc. But I also should be able to load a version with the bug, so I guess this is way.
But... how do I load the latest "released" version of 2.1 ? Ej: I have: - 2.1.3 (released) - 2.2.4 (released) - 2.3... (development) If I want to load the latest released version of 2.1, how do I do it without knowing if the latest is 2.1.3 or 2.1.15? Regards! Esteban A. Maringolo 2014-08-08 10:09 GMT-03:00 Esteban Lorenzano <esteba...@gmail.com>: > 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 > > >
