| 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: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 ...
|
| > 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'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 ...
| I would like that Metacello constraints the space. Because we should
| have less option and more structured supported scenarios.
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 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.
|
| > 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.
Exactly ... symbolic versions were invented exactly because the "recommended version" changes 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.
|
| > 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