+1 Arnaud
On Tue, Aug 26, 2008 at 8:33 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote: > I like just about every bit of this proposal. So a big +1 from me. > > 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 > > > > > -- > Dennis Lundberg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- .......................................................... Arnaud HERITIER .......................................................... OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .......................................................... ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...........................................................
