Smalltalk - Re: Managing updates/patches in Pharo with Metacello

Smalltalk › Pharo › Pharo Smalltalk Users

Re: Managing updates/patches in Pharo with Metacello

Posted by EstebanLM on Aug 08, 2014; 2:13pm
URL: https://forum.world.st/Managing-updates-patches-in-Pharo-with-Metacello-tp4772489p4772508.html

On 08 Aug 2014, at 15:31, Esteban A. Maringolo <[hidden email]> 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).

Esteban

Regards!

Esteban A. Maringolo

2014-08-08 10:09 GMT-03:00 Esteban Lorenzano <[hidden email]>:
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 <[hidden email]> 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