So where is the "release" version of 3.7?

> Ouch, I thought this was a constructive conversation to discuss the
> options, no one has to do anything and we can leave the things the way
> they are. The point brought up earlier had to do with trying to make it
> easier for an ever increasing community to understand various versions
> being published on a regular basis (good thing!) and there isn't much I
> can personally do to help you figure it out outside of writing mails for
> many reasons, including the fact that I don't directly commit any
> changes to the stream, I have no Squeak experience or free time (as much
> as I'd have liked to do all of the above). Feel free to ignore the
> suggestions, that's all they are after all, but unless I'm misreading
> you it seems they are not welcomed at the moment.
>
> Cheers!
>
> -Boris
>
> --
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
> http://tinyurl.com/r7uw4
>
> [hidden email]
>
> CONFIDENTIALITY NOTICE
>
> 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
> attachments.
>
> Thank you.
>
> > -----Original Message-----
> > From: [hidden email] [mailto:seaside-
> > [hidden email]] On Behalf Of Philippe Marschall
> > Sent: Monday, February 26, 2007 1:33 PM
> > To: The Squeak Enterprise Aubergines Server - general discussion.
> > Subject: Re: [Seaside] So where is the "release" version of 3.7?
> >
> > 2007/2/26, Avi Bryant <[hidden email]>:
> > > On 2/26/07, Philippe Marschall <[hidden email]> wrote:
> > >
> > > > That's not how Seaside is developed. We don't have such cycles. As
> > > > Lukas said, in general we use the latest Seaside version for
> > > > production applications and we certainly develop Pier and Magritte
> > > > against the latest version. You can't do that if you have open
> bugs
> > > > that you know about. Sure there are instable phases when a lot of
> > > > refactoring is going on (like start of 2.7 or lr.171+) but that's
> in
> > > > general only maybe 4 versions. If we know about a bug, we fix it,
> if
> > > > we want a feature, we implement it. This is how Seaside is
> developed.
> > > > This is why it is pointless to attach a label to a Seaside
> version.
> > >
> > > Ok, but there are processes that work for that too.  Have a branch
> > > that is 2.7-stable, and generally commit to that.  If you're doing a
> > > refactoring or feature you're not sure about, do it on
> > > 2.7-somerefactoring, then merge in when you're confident of it.  The
> > > important thing is just that everyone know what the system is.
> >
> > It's just that Monticello doesn't support this. The Monticello
> > filename hacks have to stop.  For example the filename hacks of
> > Chronos wreck havoc on the Monticello Browser. An other example my
> > Monticello marks Seaside2.8a1 as if there was a new version that I
> > haven't loaded which isn't the case. Additionally they make the
> > Seaside repository even more crowded.
> >
> > We need metadata for this and it needs to be simple to use otherwise
> > everyone marks their versions as unstable and nothing is gained. Or a
> > section on the yet to be built Seaside webpage so that people don't
> > have to access the (very confusing) repository anymore.
> >
> > So my point on this is if you want something to happen in this area is
> > be part of the solution and don't just write mails.
> >
> > Philippe
> >
> > > Avi
> > > _______________________________________________
> > > Seaside mailing list
> > > [hidden email]
> > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> > >
> > _______________________________________________
> > Seaside mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> I don't understand the push back.
>
> There are a bunch of branches.
> Seaside2.50
> Seaside2.5b7
> Seaside2.5b8
> ...
> Seaside2.7a1
>
> I would like to see a branch
> Seaside2.7 - which I would expect to be the release version.   The really
> great email by Philippe that lists all the features in the new release
> should be in the class comment of the oldest version in this branch.
>
> Any new changes in this branch are minor bug fixes.  Minor bugs discovered
> in 2.8 and fixed will have to have their fixes backported.  Keeping the list
> apprised of those fixes you make will help people improve the quality of 2.7
> while still letting you press on in 2.8.
>
> The comment in the last version of 2.7a1 BTW gives me pause:
>
> - backoff the change in mb-202 entitled "recovered essential lost input
> conversion code"
>
> That doesn't sound like a minor bug fix.  It sounds like a big change.  It
> makes versions from 202-204 suspect.

> So my complaint is that the version numbering only makes sense to you.  The
> criteria for bumping the version number only makes sense to you.  There is
> nothing for someone doing production code and desiring a stable platform to
> hang his hat on.
>
> I'm glad you're having fun.  But I'm not.
>
> -Todd Blanchard
>
>
> On Feb 26, 2007, at 2:31 PM, Philippe Marschall wrote:
>
>
> So if there is a solution it must be one of the following:
>
> - someone currently doing no work for Seaside is stepping up to do
>
> "release management" or whatever you call it
>
> - some simple change that makes it easy for contributors to deliver
>
> "stable versions"
>
>
>
>
> I'd appreciate if the discussion focuses more on these two items and
>
> not on what we could all do if this was a big time Apache project and
>
> we were all paid for doing this.
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>

> > - Create a Seaside2.7-stable branch on the SqueakSource repository
> > - Put the last version from Seaside2.7a1 to the stable branch
>
> I strongly suggest not to do so. We willl just end up having a mess in
> the SqueakSource repository with even more packages, labels, branches,
> special versions, etc. Nobody will be able to understand anymore what
> to load, what to merge, what is experimental, what is to be merged
> into what version and what is not to be merged.
>
> Monticello and SqueakSource are not ment for that, there is SqueakMap
> that provides a convenient way to load a known working version. And as
> I already said several times now, but everybody keeps on ignoring,
> there is a version of Seaside marked as 2.7-final on SqueakMap, with
> the release log of Philippe. For those that prefer to write mails
> instead of opening an image I even attached a screenshot.

> -----Original Message-----
> From: [hidden email] [mailto:seaside-
> [hidden email]] On Behalf Of Martial Boniou
> Sent: Tuesday, February 27, 2007 5:49 AM
> To: The Squeak Enterprise Aubergines Server - general discussion.
> Subject: Re: [Seaside] So where is the "release" version of 3.7?
>
> Just a suggestion. Why don't we use a versioning system a la
> linux-kernel? This system has a even/odd mark. For example, 2.7 should
> be instable/dev and so 2.8 could be tested/stable. So the developer will
> save to MC for 2.7/2.9/2.11 etc... and user only upgrade/merge the
> 2.8/2.10/3.0 version. Thus Lukas et al. continue his work without
> thinking about testing and validating and a group of developer (or Lukas
> when he's sure) post a package to the stable repository when it is
> tested and stable. Then there won't be any 2.8 ancestors in 2.7 but
> simply 2.7 to 2.7 because 2.8 (and even numbers'group) works as a drop
> box.
>
> I hope I am clear. But it could be a good solution (awaiting MC3 with
> RCS) and not a break for developers. I think it's not too bad as it is.
> Of course there is bug and broken issues but this is little glitch we
> should tolerate.
>
> Tell me what you think about that. Actually 2.8 can be 2.7-stable but
> the only rule is no code upgrade in the stable packages...
>
> --
> Martial
>
>
> stephane ducasse a écrit :
> | I would really to see an official announcement for 2.7 (when it will
> | be finished) so that we can market it well.
> |
> | Stef
> |
> | On 26 févr. 07, at 18:46, Todd Blanchard wrote:
> |
> | >I can't say it makes me feel all fuzzy about 2.7 when it is still
> | >marked alpha and people seem to have dropped it in favor of
> | >beginning 2.8.  The latest thing I can see in the repository is
> | >Seaside 2.7a1-mb.205
> | >
> | >It would be nice to see something labeled 2.7 final.
> | >
> | >-Todd Blanchard
> | >
> | >
> | >_______________________________________________
> | >Seaside mailing list
> | >[hidden email]
> | >http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> | >
> |
> | _______________________________________________
> | Seaside mailing list
> | [hidden email]
> | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> |
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> For example, I have a version of seaside stored in
> Seaside2.6g-dkh.18.mcz. This version contains Squeak source and has as
> an ancestor Seaside2.6a3-avi.73.mcz. There will be an equivalent version
> 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 Seaside2.6a3-dkh.74.mcz,
> since it contains code that is rooted in the 6a3 branch.
>
> My question is what should the version of the Gemstone code be called?
> It will be functionally equivalent to Seaside2.6a3-dkh.74.mcz, but will
> contain Gemstone specific code.

> Not to complicate the discussion too much, but...
>
> As many of you already know, we are porting Seaside to Gemstone. As part
> of that effort we have decided to port Monticello to Gemstone as well.
>
> We want to make it easy for folks to move their applications from a
> Squeak image to a Gemstone image and Monticello seems to be a natural fit.
>
> Of course, this adds an extra dimension to the naming issue: because of
> platform differences, there will be some monticello packages that are
> Gemstone specific (today _all_ monticello packages are Squeak specific).
>
> The fundamental question is should the platform be encoded in the name
> (i.e., Package_gemstone.branch-author.99) or not (implied by the branch)?
>
> For example, I have a version of seaside stored in
> Seaside2.6g-dkh.18.mcz. This version contains Squeak source and has as
> an ancestor Seaside2.6a3-avi.73.mcz. There will be an equivalent version
> 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 Seaside2.6a3-dkh.74.mcz,
> since it contains code that is rooted in the 6a3 branch.
>
> My question is what should the version of the Gemstone code be called?
> It will be functionally equivalent to Seaside2.6a3-dkh.74.mcz, but will
> contain Gemstone specific code.
>
> BTW, we already plan on hosting a Gemstone SqueakSource site, so that we
> don't pollute the site with gemstone-specific packages.

> I think that the version name should share a common branch and package
> name with a platform designator...
>
> What do you folks think?
>
> Dale
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>