Hi, On 22 Nov 2012, at 18:04, Dale Henrichs <[email protected]> wrote:
> > ----- 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 ... 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."
