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 <[email protected]> wrote: > > > ----- 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 > > -- www.tudorgirba.com "Every thing has its own flow"
