On 08 Aug 2014, at 16:13, Esteban Lorenzano <esteba...@gmail.com> wrote:
> > On 08 Aug 2014, at 15:31, Esteban A. Maringolo <emaring...@gmail.com> wrote: > >> 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? > > mmm… normally, you would move your stable symlink to the newer version. > or you can load explicitly. > or you can use something with #latestVersionMatching: and siblings (but this > one I don’t know, I never used them). forget it: ConfigurationOfBlah project latestVersion: #release. that will answer you the latest release version. Esteban > > Esteban > >> >> 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 >> >> >> >
