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

>
> 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:
>>
>> 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.
>
> 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
> brett@...
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>