[Seaside] So where is the "release" version of 3.7?
philippe.marschall at gmail.com
Mon Feb 26 21:33:10 UTC 2007
2007/2/26, Avi Bryant <avi at dabbledb.com>:
> On 2/26/07, Philippe Marschall <philippe.marschall at gmail.com> 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.
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the Seaside