Esteban, Take a look at the ConfigurationOfSeaside[1] in particular look at the `symbolic versions` protocol and note the release* symbolic versions:
bleedingEdge: development: release30: release31: release3: stable: By using a version specific symbolic version you can get your cake and eat it to. In you case you would create version 2.1.1 with the bugfix and then update the release2 and release21 symbolic versions to point to 2.1.1. In you project load specification if you are interested in using the latest 2.1 then use #release21 and you will always get the latest bugfixes. On the other hand if you have gone into production with version 2.1 (as opposed to #release21), then you do not want version 2.1.1 loaded until you've validated the changes .... It's possible that a user of your project has chosen a different solution to the bug and your fix would break their fix, so you should never modify a version that has been released. Dale [1] http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main On Fri, Aug 8, 2014 at 7:14 AM, Esteban Lorenzano <esteba...@gmail.com> wrote: > > 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 >> >> >> > > >
