please, please, let's not add anything else to trunk (2.1) and stabilize it. I've been waiting for a stable embeddable version for 2 years and with the number of work (complete rewrites of everything) in the branches, a stable maven.next looks years ahead again.
Not having an embeddable maven that works in the IDE integrations hurts the adoption and trust of users. Just my 2 cents. Milos On 8/8/08, Brian E. Fox <[EMAIL PROTECTED]> wrote: > I have been saying that the trunk is too changed for 2.1 for a while > also. I think having it as 3.0 is probably the logical thing to do and > then we can really buckle 2.0 down as it should be and start making > these bigger destabilizing fixes/small features to a 2.1 branch cut from > 2.0.10. Unless 2.0.10 gets worked out real soon, perhaps we even go back > to 2.0.9 and branch there (ie 2.0.10 becomes 2.1.0) > > > -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 07, 2008 11:16 PM > To: Maven Developers List > Subject: Re: Versioning Maven (was: Re: Maven 2.1 development IRC > roundtable) > > > On 08/08/2008, at 12:24 PM, Paul Benedict wrote: > > > Is TRUNK really 3.0? Hmm.. Maybe not. I think it is only appropriate > > to bump the first number when you make a major architecture change. It > > was totally appropriate between 1.x and 2.x because the code bases are > > absolutely incompatible. Why I should believe the same for TRUNK now? > > It still looks like 2.1 -- evolution -- not 3.0 -- revolution. Let's > > not forget this famous popular Apache email > > A significant advance would warrant a 3.0, incompatibility is not a > requirement. If it can still be backwards compatible then all the > better (though managed incompatibilities would be acceptable). Look at > Jetty, Tomcat, etc. Some major releases required migration, some didn't. > > > http://incubator.apache.org/learn/rules-for-revolutionaries.html > > I definitely think that's a good way to operate, and it's a good, > quick, read. > > Most of the work being proposed is operating under these rules to some > extent. It's been done in the sandbox or branches for later proposal > for inclusion/replacement of trunk. It's definitely revolutionary - > every subsystem is being reviewed or replaced to give us the ability > to fix some of the more challenging issues. Even though I'm sure there > is consensus that is the right way to go, timing is the issue. There > is not consensus that it should be Maven.NEXT. > > Right now our evolutionary track is 2.0.x, and that seems wrong to a > lot of people. It limits us to very few improvements as folks are > expecting only bugfixes, with good reason. > > But also our evolutionary track needs to be something we can release, > and that's not trunk today. Taking 2.0.10 as a baseline and applying > some sensible, well managed improvements (which may well include > adopting the alternate project builder, for example, as well as others > already mentioned) makes a lot of sense. > > Cheers, > Brett > > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
