----- Original Message ----- | From: "Tudor Girba" <[email protected]> | To: "pharo-project" <[email protected]> | 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 ... | - 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. 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:) 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 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. Dale
