oh, and one more thing. I'm willing to add a helping hand with stabilisation, however I've been burned a few times in the past when I did. There's no point fixing any issue when 2 weeks later everything gets washed away and changed completely.
Milos On 8/8/08, Milos Kleint <[EMAIL PROTECTED]> wrote: > 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]
