Smalltalk › Pharo › Pharo Smalltalk Users

Managing updates/patches in Pharo with Metacello

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Esteban A. Maringolo

Managing updates/patches in Pharo with Metacello

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

stepharo

Re: Managing updates/patches in Pharo with Metacello

On dev I used the latest
Once published, backport bugs produced specific version that are merged

Ex
released
V11PackageA

dev latest
V21PackageA

=>

released
V12PackageA (merged from V11 and V22)

dev latest
V22PackageA

> i,
>
> 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

EstebanLM

Re: Managing updates/patches in Pharo with Metacello

In reply to this post by Esteban A. Maringolo

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

Esteban A. Maringolo

Re: Managing updates/patches in Pharo with Metacello

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 <[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

Esteban A. Maringolo

Re: Managing updates/patches in Pharo with Metacello

In reply to this post by stepharo

I think you're mixing two concepts here, the project code and build artifact.
Otherwise I didn't understand your explanation :)

Esteban A. Maringolo

2014-08-08 10:01 GMT-03:00 stepharo <[hidden email]>:

>
> On dev I used the latest
> Once published, backport bugs produced specific version that are merged
>
>
> Ex
> released
> V11PackageA
>
> dev latest
> V21PackageA
>
> =>
>
> released
> V12PackageA (merged from V11 and V22)
>
>
> dev latest
> V22PackageA
>
>
>
>
>> i,
>>
>>
>> How do you manage released versions updates in Metacello?

Sean P. DeNigris

Re: Managing updates/patches in Pharo with Metacello

Administrator

In reply to this post by Esteban A. Maringolo

Esteban A. Maringolo wrote

I was afraid of populating the Metacello config with lots of #version21:
#version211: #version212, etc.

Config classes are just the way we serialize projects. It is like reading binary :) I wouldn't contort your workflow to make them easier to read in a browser. Have you tried Versionner?

Cheers,
Sean

EstebanLM

Re: Managing updates/patches in Pharo with Metacello

In reply to this post by Esteban A. Maringolo

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

EstebanLM

Re: Managing updates/patches in Pharo with Metacello

On 08 Aug 2014, at 16:13, Esteban Lorenzano <[hidden email]> wrote:

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).

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 <[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

Dale Henrichs-3

Re: Managing updates/patches in Pharo with Metacello

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 <[hidden email]> wrote:

On 08 Aug 2014, at 16:13, Esteban Lorenzano <[hidden email]> wrote:

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).

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 <[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