The question is the same I asked when you introduced them :): Why are symbolic versions treated differently from normal ones? This has two dimensions: - why have a different pragma at all? - why have the distinction between symbols and versions, given that there will never be a regular version named 'stable'? Cheers, Doru On 21 Nov 2012, at 19:27, Dale Henrichs <dhenrich@vmware.com> wrote:

Stef,

I'm not sure which context you are talking about ... the symbolic version #stable can be used as an argument anywhere that the linear version '1.1' can be used, so I think that it is true that symbolic versions can be used in a #version: message ...

So I guess I need a little more context ...

Dale

----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | Sent: Friday, November 16, 2012 2:19:02 PM | Subject: [Pharo-project] Metacello Why symbolicversion and not simply tagged version:? | | Dale | | in my goal to reduce the complexity of metacello, I'm wondering why | symbolic versions could not be expressed as version: | | because | | version: #stable | version: #development | | are symbolic versions and there is no clash possible with | | version: '1.1' | | Stef | |

-- www.tudorgirba.com "Things happen when they happen, not when you talk about them happening."

On Nov 21, 2012, at 8:16 PM, Dale Henrichs wrote:

Doru,

I guess because I don't agree that the following statement would be true:

there will never be a regular version named 'stable'

I know that in git I can have a branch named 'stable' and a tag named 'stable' and that causes problems ... for me.

Besides, the set of symbolic versions is not restricted to #stable and #development ... one could choose to define a symbolic version called #default or #'1.0'…

I would not. I would like that Metacello constraints the space. Because we should have less option and more structured supported scenarios.

I intend for there to be two namespaces the linear version namespace and the symbolic version namespace to make a clear distinction between the two, because they have different semantics.

Ok it was not clear to me that they have a different semantics.

One shouldn't be surprised that when version #stable of project foo is loaded the current version of the project is '1.0' on one day and '1.1' on the next.

How this can be possible? Ok you mean because the guy changed the stable definition.

Or when they load #'1.0' that the current version is '1.0-beta.19'.

This distinction is obviously not important to you and I am okay with that:)

Dale

----- Original Message ----- | From: "Tudor Girba" <tudor@tudorgirba.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, November 21, 2012 10:50:37 AM | Subject: Re: [Pharo-project] Metacello Why symbolicversion and not simply tagged version:? | | The question is the same I asked when you introduced them :): | Why are symbolic versions treated differently from normal ones? | | This has two dimensions: | - why have a different pragma at all? | - why have the distinction between symbols and versions, given that | there will never be a regular version named 'stable'? | | Cheers, | Doru | | | On 21 Nov 2012, at 19:27, Dale Henrichs <dhenrich@vmware.com> wrote: | | > Stef, | > | > I'm not sure which context you are talking about ... the symbolic | > version #stable can be used as an argument anywhere that the | > linear version '1.1' can be used, so I think that it is true that | > symbolic versions can be used in a #version: message ... | > | > So I guess I need a little more context ... | > | > Dale | > | > ----- Original Message ----- | > | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | > | To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> | > | Sent: Friday, November 16, 2012 2:19:02 PM | > | Subject: [Pharo-project] Metacello Why symbolicversion and not | > | simply tagged version:? | > | | > | Dale | > | | > | in my goal to reduce the complexity of metacello, I'm wondering | > | why | > | symbolic versions could not be expressed as version: | > | | > | because | > | | > | version: #stable | > | version: #development | > | | > | are symbolic versions and there is no clash possible with | > | | > | version: '1.1' | > | | > | Stef | > | | > | | > | | -- | www.tudorgirba.com | | "Things happen when they happen, | not when you talk about them happening." | | |

Hi Dale, I think your concerns are not consistent :): - you make a distinction between symbolic and regular versions, but you do not make a distinction between baseline and regular versions. Why not? Because it is good practice to have a proper naming that distinguishes between baseline and the regular versions without having this distinction hardcoded in the engine. And it works just fine. Of course, people can mess it up by having a version called 'baseline', but in practice it works just fine. The same could apply to symbolic versions. - you say that when people load a '1.0' symbolic version they would be confused when they in fact get '1.0.37'. I think it will be equally confusing when the symbolic version is named #'1.0'. The problem is really that the name of the symbolic version should be different. Cheers, Doru On Thu, Nov 22, 2012 at 12:36 AM, Dale Henrichs <dhenrich@vmware.com> wrote:

----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, November 21, 2012 2:34:36 PM | Subject: Re: [Pharo-project] Metacello Why symbolicversion and not simply tagged version:? | | | On Nov 21, 2012, at 8:16 PM, Dale Henrichs wrote: | | > Doru, | > | > I guess because I don't agree that the following statement would be | > true: | > | > there will never be a regular version named 'stable' | > | > I know that in git I can have a branch named 'stable' and a tag | > named 'stable' and that causes problems ... for me. | > | > Besides, the set of symbolic versions is not restricted to #stable | > and #development ... one could choose to define a symbolic version | > called #default or #'1.0'… | | I would not.

I would not, at least right now... But someday, #stable may not be sufficient it may be necessary to reason about "the #stable version of Metacello 1.0 and the #stable version of Metacello 2.0", then #'1.0' and #'2.0' may turn out to be useful ...

| I would like that Metacello constraints the space. Because we should | have less option and more structured supported scenarios.

I'm not sure that we know the extent of the space quite yet, but for now we have a convention where we are primarily using only the #stable symbolic version so we've successfully avoided a proliferation of symbolic versions which is a good thing ...

As I do more work with git I see the linear versions become more like tags of specific git commits with the burden of version management falling onto git instead of Metacello. Then with platform-specific branches in the git repository it becomes possible to use a cross branch tag (a linear version) which may obsolete symbolic versions altogether, but it is way too early in the learning curve with git to tell...

| | > I intend for there to be two namespaces the linear version | > namespace and the symbolic version namespace to make a clear | > distinction between the two, because they have different | > semantics. | | Ok it was not clear to me that they have a different semantics.

I think it is important that we have a language that differentiates between a linear version '1.0' which refers to a specific set of packages that do not change over time and a symbolic version #stable (or #'1.0') which refers to a family of related versions the members of which may change over time.

| | > One shouldn't be surprised that when version #stable of project foo | > is loaded the current version of the project is '1.0' on one day | > and '1.1' on the next. | | How this can be possible? Ok you mean because the guy changed the | stable definition.

Exactly ... symbolic versions were invented exactly because the "recommended version" changes over time ....

| | > Or when they load #'1.0' that the current version is '1.0-beta.19'. | > | > This distinction is obviously not important to you and I am okay | > with that:) | > | > Dale

-- www.tudorgirba.com "Every thing has its own flow"

Hi, On 22 Nov 2012, at 18:04, Dale Henrichs <dhenrich@vmware.com> wrote:

----- Original Message ----- | From: "Tudor Girba" <tudor@tudorgirba.com> | To: "pharo-project" <Pharo-project@lists.gforge.inria.fr> | Sent: Thursday, November 22, 2012 3:15:36 AM | Subject: Re: [Pharo-project] Metacello Why symbolicversion and not simply tagged version:? | | Hi Dale, | | | I think your concerns are not consistent :): | | | - you make a distinction between symbolic and regular versions, but | you do not make a distinction between baseline and regular versions. | Why not? Because it is good practice to have a proper naming that | distinguishes between baseline and the regular versions without | having this distinction hardcoded in the engine. And it works just | fine. Of course, people can mess it up by having a version called | 'baseline', but in practice it works just fine. | | The same could apply to symbolic versions.

You're really stretching here, Doru ... I would claim that not making a distinction between baselines and versions was a mistake that should not be repeated with symbolic versions ...

Ok. We disagree on this one :). This is because in practice, it is not a problem.

| - you say that when people load a '1.0' symbolic version they would | be confused when they in fact get '1.0.37'. I think it will be | equally confusing when the symbolic version is named #'1.0'. The | problem is really that the name of the symbolic version should be | different.

I see the difference between '1.0' and #'1.0' and I assume that you are able to perceive that difference as well:)

For me the important message to take from this is that the fact that Metacello must be involved in version control is the real travesty here ... not the invention of symbolic versions:)

If one starts to use a version control system that can manage more than one file at a time like git/svn/mercurial/etc. you quickly find out that the need to monkey with linear versions begins to fade away, because the primary function of the linear version is to act as a version control data base ...

When using git I use a BaselineOf which has a single baseline specification. There's no need to distinguish between different baseline specifications and the notion of baseline version disappears... The ConfigurationOf relegates the linear versions to the role of tags with no need to maintain an exhaustive list of mcz file names ... So with git Metacello begins to explicitly distinguishes between baselines (configurations) and versions (tags). I don't need to use a ConfigrationOf for development at all ... The ConfigurationOf becomes a deployment/publishing artifact.

Precisely. So, you see: that shows that introducing a BaselineOf uses the mechanism of a regular version and it is enough.

The fate of symbolic versions in the presence of git is still up in the air...It may be possible to simply stop using symbolic versions, I would think...The fate of symbolic versions is the least of my worries:)

Dale, I just clarified what Stef was asking. I still think it is a valid concern for those that do not work on Git.

Frankly Doru, I would welcome your critical eye applied to the Metacello Preview. I think that managing Moose with git would simplify a number of your development problems. Perhaps this whole linearizing the packages thing would just disappear? I'm pretty sure your fixation on symbolic versions would go away:)

I am not fixated. I just see an extra concept that is not needed :). I am still interested in looking into this, but my time is severely limited these days.

I haven't released the Preview precisely because I want critical feedback before setting features in stone by releasing them ... As it stands the Metacello Preview is production ready (I've been using it constantly in my work for months now)...

Metacello dipped it's toe into the version control business out of necessity, but Metacello is not a complete version control system and I really have no desire to add branching and merging features to Metacello ... those features are the domain of a version control system .... Truly the whole Metacello story gets much simpler when one can leverage a fully-featured version control system.

I am not sure I quite understand that part in the context of dependencies to independent projects. You would still need to somehow refer to a version of the sub-project. How is that achieved? Cheers, Doru -- www.tudorgirba.com "Quality cannot be an afterthought."