[Seaside] So where is the "release" version of 3.7? - while we'reon the subject

Boris Popov boris at deepcovelabs.com
Tue Feb 27 19:28:22 UTC 2007

Speaking of complexities, we'd stopped paying much attention to versions
a long time ago and primarily use version tree view here, see attached.
Could similar presentation work for MC?


DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

boris at deepcovelabs.com


This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any

Thank you.

> -----Original Message-----
> From: seaside-bounces at lists.squeakfoundation.org [mailto:seaside-
> bounces at lists.squeakfoundation.org] On Behalf Of Avi Bryant
> Sent: Tuesday, February 27, 2007 11:21 AM
> To: The Squeak Enterprise Aubergines Server - general discussion.
> Subject: Re: [Seaside] So where is the "release" version of 3.7? -
> we'reon the subject
> On 2/27/07, Dale Henrichs <dale.henrichs at gemstone.com> wrote:
> > For example, I have a version of seaside stored in
> > Seaside2.6g-dkh.18.mcz. This version contains Squeak source and has
> > an ancestor Seaside2.6a3-avi.73.mcz. There will be an equivalent
> > that contains the Gemstone source.
> >
> > After the discussion of the last few days, I assume that the squeak
> > version should be stored in a package called
> > since it contains code that is rooted in the 6a3 branch.
> >
> > My question is what should the version of the Gemstone code be
> > It will be functionally equivalent to Seaside2.6a3-dkh.74.mcz, but
> > contain Gemstone specific code.
> This isn't a direct answer to your question, but - after trying both
> ways, I've found it better to keep the MC version number steadily
> increasing across branches.  So if I have Seaside2.7-lr.100 and I want
> to make a gemstone branch of it, that would be Seaside2.7g-avi.101,
> not Seaside2.7g-avi.1.  That way, regardless of the branch names, we
> can always get a pretty good sense of where a given version fits into
> the chronology just by looking at the name.
> BTW, for those who may feel like we're encoding way too much in the
> names: the reality is that if you're looking at a list of versions,
> whether in a repository or on your harddrive or in a mailing list
> post, most of the time all you're going to see or want to type is the
> filename.  So although it would be great to *also* have metadata for
> all of this (branch, platform, number), I do think it's important to
> talk about naming conventions as well.
> Avi
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
-------------- next part --------------
A non-text attachment was scrubbed...
Name: versions.png
Type: image/png
Size: 8231 bytes
Desc: versions.png
Url : http://lists.squeakfoundation.org/pipermail/seaside/attachments/20070227/02e6835c/versions-0001.png

More information about the Seaside mailing list