[Cuis] Fwd: Re: DIRECT version number

[Phil (list)]

On Thu, 2015-07-23 at 14:09 +0000, H. Hirzel wrote:
> 1) and 2) sounds like there is a need for an Ubuntu type of approach.
> 
> Labelled releases at regular intervals -- could be semi-annually or
> annually. Some of them receive important bux fixes thus constituting
> Long Term Releases.
> 

LTS releases are a *lot* of work and add quite a bit of drag.
Back-porting can be as much work as forward-porting (sometimes more.)  I
was thinking we start off as streamlined as possible: when 4.3 is
released, it becomes the stable branch.  At some point 4.4 (or whatever
version # makes sense) is nearing release and there is some period of RC
status for it.  When 4.4 goes stable, 4.3 is retired an so on.  That way
we only have one stable release at a time to be concerned with.

Also on the subject of LTS, I think we want to be careful not to get
into a Debian mode of operation.  That results in extreme stability at
the price of glacially slow change.

> Or stable vs unstable branches in github.
> 
> In two days on the 25th of July it will be exactly 2 years after the
> last release of 4.2.   :-)
> 

It's safe to say 2 years is a bit long between stable releases while 3
months would probably be too short.  I like yearly, but every 6 months
works too.  Since there's probably going to be a period of something
along the lines of RC status (a week?  a month?  no idea...) you don't
want the releases too often or you're chewing up a lot of time preparing
and testing releases and people are complaining that releases are too
frequent.  But that's just me spit-balling... I'm fine with whatever
people prefer.

> A point to consider as well is that what Juan is doing constitutes a
> trunk from which releases are forked from time to time by other
> people. The ones who run Feature Tests ....
> 

How this gets implemented depends largely on Juan's preference.  I guess
the way I envisioned it is that most of the changes being made could go
directly to stable (i.e. they are *mostly* bug fixes and behind the
scenes improvements).  Unless I'm mistaken, no one is really complaining
that a change might temporarily break something as the fixes for those
is almost always quick to arrive and don't require changes on our end
(at least nothing that I can recall.)  This would be more about changes
that will break/alter the behavior of the public APIs (i.e. there's good
reason to expect code breakage), either that goes into a
development/alpha branch or could be managed similarly to how I
*believe* Juan is handling Morphic 3 (i.e. changesets/packages that
don't get applied to stable but rather batched up until they're ready
for release driven both by the development effort and release timing)

For example, the FileMan code is something that I would be fine having
introduced in the middle of a stable branch's lifecycle.  Just don't
'flip the switch' on it (i.e. breaking code compatibility from an API
standpoint) until the next major stable release when there is sufficient
notice and documentation for people to make the move.  For me, it's all
a question of 'will the change break my code?'  I rather like bug fixes,
new features, and workflow improvements enough that to the extent
possible these should be encouraged in stable.  Would that be too
aggressive for you?

> --Hannes
> 
> On 7/23/15, Juan Vuletich <juan at jvuletich.org> wrote:
> > On 7/19/2015 9:39 PM, Phil (list) wrote:
> >> ...
> >> It really comes down to what is Cuis?  Is it:
> >>
> >> 1) a minimal Smalltalk that you play around with ideas / prototype
> >> something in the short to intermediate term
> >>
> >> 2) a platform that you can take that idea you were playing around with,
> >> and if it proves out, build something more substantial from for the
> >> longer term
> >>
> >> 3) a completely experimental environment.  Anything can change at any
> >> time.  Supporting 1 is doable but 2 is doubtful.
> >>
> >> Right now, Cuis is great at 1 but seems like it should be able to handle
> >> both 1 and 2 if a bit of stability gets added.  I don't think it's 3 at
> >> all, but who knows, others may disagree.  If others look at it
> >> differently, I'd love to know how you look at Cuis.
> >
> > I want Cuis to be both 1 and 2. If we are not there yet, we'd walk that
> > way.
> >
> > Cheers,
> > Juan Vuletich
> >
> > _______________________________________________
> > Cuis mailing list
> > Cuis at jvuletich.org
> > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
> >
> 
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org