Why not use JIRA voting as a mechanism, officially. Or at least as a
weighting factor.
Christian.
On 25-Aug-08, at 16:44 , 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
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
---------------------------------------------------------------------
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]
