maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Benedict" <>
Subject Re: [PROPOSAL] Going forward with Maven 2.x releases
Date Tue, 26 Aug 2008 00:58:48 GMT
I am okay with making 2.0.10 -> 2.1.0 too, but I do have to ask is
everyone up to maintaining 3 code streams (3.0, 2.0, 2.1)? In terms of
software design, the branching makes alot of sense, but due to the
amount of Critical and Blocker bugs that go into each 2.0.x release, I
don't know if that's the best plan for everyone's volunteer time.


On Mon, Aug 25, 2008 at 6:33 PM, Brett Porter <> wrote:
> On 26/08/2008, at 6:44 AM, John Casey wrote:
>> To start, I'd personally prefer to see the code we current have in the
>> release process designated as 2.1.0. It's seen a lot of change to the
>> internal implementations, and while we've gone to great lengths to ensure
>> it's functionally compatible with 2.0.x, it contains a fairly risky level of
>> change for a revision release. This means that the 2.0.x branch would be
>> rolled back to the 2.0.9 release, and we'd proceed toward a 2.0.10 that
>> fixes the worst of the regressions with a minimal of code change. At that
>> point, I'd prefer to see 2.0.x go into end-of-life mode soon, with 2.1 and
>> later replacing it.
> +1
>> From there, I'd propose that we make a plan. I think we have a long list
>> of features we'd like to implement and other features we'd really like to
>> reimplement. No doubt each of us has his/her favorites, but what I'd like to
>> suggest is using the survey tool we used for the plugin priorities to come
>> up with a ordered set of priorities for the features we want to include.
>> Then, we can chop that list up (maybe every fourth feature), and call them
>> 2.2, 2.3, 2.4, etc. At this point, 2.1 would be a baseline that is as near
>> as possible to perfect compatibility with 2.0.x, and 2.1.1 might fix
>> regressions in that code until we have the agreed-upon features for 2.2
>> done.
> +1 to the approach. I like the idea of having a clear objective for when it
> is "done". I think we could do milestone/beta releases along the way to get
> some feedback on the new features.
> I would lean towards still doing that for 2.1: make the current 2.0.10 code
> a milestone/beta release to see how it goes in the wild as is (I believe
> these will still get reasonable exposure), and pick off 3 or 4 important
> features to include for the final release. However, if consensus is to just
> go as is for 2.1 and immediately move to 2.2 that's fine with me too.
> I say this because we basically already have implementations for reactor
> changes, pgp security, and parallel downloads, for example. I'm watching the
> secure passwords thing with keen interest as well, and I know Ralph has
> something in mind I think for MNG-612 which is the most voted for feature -
> so these could be done in a managable fashion in a short amount of time to
> have a fairly compelling upgrade release. About the only other thing I'd add
> to that is a review of what behaviour we want to deprecate so we can start
> getting it out in subsequent versions, and move all other features to 2.2+.
>> In case you're concerned about who's going to drive the items on this
>> list, my own feeling is that it needs to capture the sense of the
>> development community. To that end, the survey should be conducted among
>> developers, without direct input from users. However, each developer should
>> be acting in the interests of the user community at least part of the time,
>> so we need to focus on balancing the cool with the useful to make sure our
>> releases are relevant to users.
> +1, I'm happy with starting to encourage JIRA voting as the way to guide
> features that are in demand by users.
>> Of course, it also means that all of us will sometimes have to be patient
>> for the feature near and dear to our hearts to come up in the release plan,
>> and help get the other things out of the way first. However, I think this
>> could help us unify a lot of the different directions we all seem to be
>> heading WRT Maven's core, and maybe keep things moving forward at a steady
>> pace.
> Need to be careful with this - I would say we choose the features that
> people are willing to work on. As long as someone is upfront about what they
> are going to do, it is done properly and we agree that it's good for Maven,
> we should have room to add things to the release. It's a balance - we don't
> want to get in the way of good work, but we don't want to lose focus either.
> I think it would be a non-issue if we have some clear objectives set out up
> front since the willing contributors are involved in both parts of the
> process. Common sense will dictate whether something is a good addition or a
> disruptive change at the time.
>> To get things started, we have a long list of proposals out here:
>> Also, from users, we have these:
>> But I'm sure this is at most 10% of what people have in mind for Maven.
>> Maybe we can have a short discussion of things we need to be doing in the
>> relatively near term for the health of Maven, then cap that discussion and
>> turn it into a survey to help us consolidate priorities. Then, we can chop
>> them up into a release plan and get started.
> Sounds good. How about we open the permissions on the MAVEN space to
> everyone and move all the proposals into one place?
> Cheers,
> Brett
> --
> Brett Porter
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message