maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Milos Kleint" <mkle...@gmail.com>
Subject Re: Versioning Maven (was: Re: Maven 2.1 development IRC roundtable)
Date Fri, 08 Aug 2008 16:40:32 GMT
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 <brianf@reply.infinity.nu> 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:brett@apache.org]
>  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
>  brett@apache.org
>  http://blogs.exist.com/bporter/
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>  For additional commands, e-mail: dev-help@maven.apache.org
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>  For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message