----- Original Message ----- | From: "Stéphane Ducasse" <[email protected]> | To: [email protected] | 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
