Would you mind running with the latest code on the RC branch? I ran it,
but I'm not sure I have the environment setup the way people would
expect. The SVN for that branch is:
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.10-RC
Ralph Goers wrote:
Yeah, I don't think you need to be all that selective. I agree that
2.1.0 needs all the work you've been doing. I just ran the cxf build on
the 2.1.x branch. Here are the results I get when running mvn
-Pfastinstall install:
4:49 for 2.0.9,
8:51 on 2.1.x
8:41 on 2.1.x with my changes.
Memory usage was about the same on all of them. I'm not sure why it was
a little faster with my changes. It probably isn't really any different.
From what I can tell my changes shouldn't affect the cxf build.
Ralph
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.
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.
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.
Ralph Goers wrote:
My non-binding preference is for option 1. I'm not crazy about
renaming 2.0.10-RC. I'd really be surprised if merging that to 2.1.x
would be all that hard.
Brett Porter wrote:
This doesn't particularly appeal to me. maven-2.0.x is stranded in a
half merged state.
The current 2.1.x was cut from 2.0.x and I figured we'd just merge
everything that hit maven-2.0.x.
I'd prefer one of
1) merge all your stuff selectively to 2.1.x (along with Dan's
changes), and roll 2.0.x back (but keep other bug fixes we can
release as 2.0.10)
2) carry on the 2.0.10 approach
It seems like 2 is becoming less feasible though due to the extent
of changes it has needed for an RC branch?
Maybe not completely thought through - I'm rushing out the door for
a long weekend :) Will respond to your other mails Monday.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
