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]
