Re: [PROPOSAL] Going forward with Maven 2.x releases

> I'm good with making 2.0.10-RC the head of 2.1.x.  I guess I'd like to
> see some sort of process on 2.1 where enhancements that aren't
> necessarily 100% compatible can be added so some things can be changed
> before the branch is considered completely stable.  By releasing 2.1.0 I
> think we'd be giving the wrong impression. So I would prefer that there
> be some number of milestone releases before 2.10 is done.  I'd expect 1
> or two more 2.0.x releases while 2.1 is in this mode.
>
> Ralph
>
>
> John Casey wrote:
>> Hi,
>>
>> I'd like to propose that we put together a plan for the next few
>> releases of Maven, and also a plan for what we're going to call them.
>> There has been quite a bit of discussion here, on IRC, and in the back
>> channels about how to structure this, so let's see if we can reach a
>> consensus.
>>
>> 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.
>>
>> 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.
>>
>> We could stay two or three major releases ahead of ourselves using
>> this list, and triage new feature requests as they come up, to see if
>> we need to reshuffle the release plan. The point is, without putting
>> calendar dates on things, we'd be putting together a what - and,
>> relatively speaking, when - plan for our releases that we could publish.
>>
>> 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.
>>
>> 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.
>>
>>
>> To get things started, we have a long list of proposals out here:
>>
>> http://docs.codehaus.org/display/MAVEN/All+Proposals
>>
>>
>> Also, from users, we have these:
>>
>> http://docs.codehaus.org/display/MAVENUSER/User+Proposals
>>
>>
>> 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.
>>
>> Does this make sense? Does anyone feel that this is wildly off target?
>>
>> -john
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>