Hi John,
On 22/08/2008, at 10:35 AM, John Casey wrote:
As far as selective merging to 2.1.x, of course we'll keep things
like Dan's change, but where does that leave all of the stabilizing
work on the RC branch? Most of the substantive changes in the RC
branch is also in the 2.1.x branch, so to me it makes more sense to
sync 2.1.x up with the RC branch (the 2.1.x branch should accept all
of the RC branch changes, and incorporate the new code such as Dan's
and Ralph's work). I guess I'm not sure how to interpret the
'selective' part of option 1.
Yeah, sorry - I'm not quite sure why I threw 'selectively' in there.
As you say, everything should go to 2.1.x. The only question was what
to do with 2.0.x - it either needs to go back (before the regressions
from 2.0.9 that have mostly been corrected on the RC branch) or
forward (to catch up to the RC branch).
Then, we can roll back the 2.0.x branch and decide how to move
forward there to fix the worst problems with 2.0.9. The extent of
changes in the RC branch make it a little risky to say the least for
a 2.0.10 release. It's not that it's functionally that different
from the other 2.0.x releases, but the implementations have changed
significantly.
At any rate, we've put in an awful lot of work on this RC branch to
simply discard the stability we've achieved and resume work toward
some as-yet-undetermined release date.
+1
I still have a slight preference for pursuing the 2.0.10 release as is
since it seems very close and worthwhile. The stabilisation work needs
to happen either way, and it seems a waste to invest effort in rolling
back the 2.0.x and then pushing changes back in again. But if you
think it's more 2.1 worthy that's fine with me too. Just my $A0.02.
Whichever way it goes, we need to get the branches in a consistent
state ASAP... we're back to holding off any changes on 2.1.x in case
this replaces it :) Likewise, nobody could pick up anything for 2.0.11
on the 2.0.x branch.
I have a strong preference to get the code in the RC branch released
under *some* version very soon now, then regroup to incorporate any
changes from Dan or Ralph that might destabilize things again. There
are important fixes in this code, and one of the big advantages of
pushing trunk to 3.0.x was to allow a release of intermediate code
in the near future...let's not throw that away.
I think Dan's change is safe to include from what I've seen so far,
still need a bit of time for a closer look. If it has integration
tests and documentation it should be good to go :)
Maybe we're looking more at a 2.1-M1/2.1.0-beta-1 release to get it
out sooner but with an appropriate "disclaimer"? Just another
suggestion.
(I'm sure this is the point Wendy will jump in to suggest httpd-style
versioning for the 2.1.x series - I'm almost being won over to that
argument...)
Cheers,
Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
