On Apr 22, 2008, at 2:58 PM, Charles Oliver Nutter wrote:
Thomas E Enebo wrote:
I would like to keep putting out 1.1.x until we encounter something
which changes existing semantics. I don't consider 1.8.7 as a big
change. All the stuff in 1.2 can be in point releases of 1.1.x.
Actually additions to 2.0 (rubinius/1.9) can also be done during
point
releases of 1.1.
Tom hates branches. I do not, but I recognize they're cumbersome.
If you're using subversion, then yes. On git they're extremely cheap
and practically a pleasure to work with. I wish that mercurial inline
branches were the same thing, but everything I've read about them lead
me to believe that they're not. And I don't buy into the "clone your
repo to make a branch" approach (yet).
"Innovation" on the 1.0 line stopped the minute that branch was
created, and while I think that was probably the right thing to do
to stabilize 1.0, 1.1 is already in far better shape and we're not
likely to do serious damage in the short term. So I think continuing
to develop off trunk can work for a while.
I also agree that we can keep even larger additions in trunk and
pull off dot releases where those features are present but perhaps
not supported. Adding is easy to do without breaking a lot of stuff.
The key to whether we should finally pull off a branch would be when
we reach the point we need to rewrite some major part of the system
in a user-visible way. Java integration would do that, and obviously
anything relating to lightweights would as well.
I agree that I'd prefer to not maintain more than one or two branches
at a time under subversion. But it might be easier if we were using a
better tool that allowed repeated merges between multiple branches,
plus distributed development, etc. etc.
So begin the monthly SCM flame wars again :)
/Nick
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
