[PROPOSAL] Going forward with Maven 2.x releases

[John Casey-5]

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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Christian Edward Gruber-2]

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: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[brettporter]

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@...

[Paul Benedict-2]

I am okay with making 2.0.10 -> 2.1.0 too, but I do have to ask is
everyone up to maintaining 3 code streams (3.0, 2.0, 2.1)? In terms of
software design, the branching makes alot of sense, but due to the
amount of Critical and Blocker bugs that go into each 2.0.x release, I
don't know if that's the best plan for everyone's volunteer time.

Paul

On Mon, Aug 25, 2008 at 6:33 PM, Brett Porter <brett@...> wrote:

>
> 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@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ralph Goers]

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@...

[Ralph Goers]

I should have read your email before I replied. I pretty much agree with
all of what you are proposing. FWIW, the bug I am working on is MNG-624
and yes, it has a ton of votes. It also addresses MNG-3057, MNG-2446,
MNG-2412 and probably several others that are related. My change is
pretty much working but I want to test more and unfortunately it is on
the current 2.1.x branch which runs terribly slow. I am sure I am going
to have conflicts when I try to merge it in with 2.0.10-RC so I am not
in too much of a hurry to commit it anywhere until we figure out which
branch is the "real" 2.1.x.

Ralph

Brett Porter wrote:

>
> 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@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[John Casey-5]

I'm okay with making the current RC a first milestone toward 2.1.0, if
we know what the endgame for 2.1.0 is. How do we know when we're done?
Also, can we focus on having a 2.1.0 GA out in the next two or so
months? It's been since April that we had a release, and that one had
some pretty big problems that are keeping people away. I don't want to
set the bar too high on these releases, especially when there's so
little development time to go around. IMO, if we can start out with
*some* success, we can build off of that and keep things moving.
Personally, I'd much rather see 3-4 new features every three months in a
GA release, instead of 12-16 new features in a year. It also gives us a
much better chance of making our releases stable and predictable.

As far as the performance problems on the 2.1.x branch, that's on my
todo list for tomorrow, to merge in my changes from the RC branch to get
the 2.1.x branch back up to snuff. Sorry that's been slow coming (no pun
intended) but I'm starting to get caught up WRT SVN syncing now, so
hopefully tomorrow will be the day.

As far as supporting 3 codelines, my own thought is to keep 2.0.x on
life support long enough to get a GA release of 2.1 out (and maybe a
little longer, I don't know what's really feasible here), but not to
spend too much time spit-shining 2.0.x anymore. If we can find a way to
fix the most broken features without bringing down the rest of that
house of cards, then that'll be good enough for me.

Brett, Christian, I think JIRA voting is a great way to "weight" the
survey results with the users' priorities, but I want to make sure we
have an alternate mechanism that allows us to talk about features -
which will be sets of JIRA issues, in reality - outside of an
issue-tracking context. We need to use Confluence for this sort of work,
writing proposals that can be reviewed and voted on, IMO. I was just
thinking that Dennis' use of the survey system was a great idea, and
could be a perfect fit for this sort of planning.

-john

Ralph Goers wrote:

> I should have read your email before I replied. I pretty much agree with
> all of what you are proposing. FWIW, the bug I am working on is MNG-624
> and yes, it has a ton of votes. It also addresses MNG-3057, MNG-2446,
> MNG-2412 and probably several others that are related. My change is
> pretty much working but I want to test more and unfortunately it is on
> the current 2.1.x branch which runs terribly slow. I am sure I am going
> to have conflicts when I try to merge it in with 2.0.10-RC so I am not
> in too much of a hurry to commit it anywhere until we figure out which
> branch is the "real" 2.1.x.
>
> Ralph
>
> Brett Porter wrote:
>>
>> 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@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[brettporter]

+1 :)

On 26/08/2008, at 1:57 PM, John Casey wrote:

> I'm okay with making the current RC a first milestone toward 2.1.0,  
> if we know what the endgame for 2.1.0 is. How do we know when we're  
> done? Also, can we focus on having a 2.1.0 GA out in the next two or  
> so months? It's been since April that we had a release, and that one  
> had some pretty big problems that are keeping people away. I don't  
> want to set the bar too high on these releases, especially when  
> there's so little development time to go around. IMO, if we can  
> start out with *some* success, we can build off of that and keep  
> things moving. Personally, I'd much rather see 3-4 new features  
> every three months in a GA release, instead of 12-16 new features in  
> a year. It also gives us a much better chance of making our releases  
> stable and predictable.
>
> As far as the performance problems on the 2.1.x branch, that's on my  
> todo list for tomorrow, to merge in my changes from the RC branch to  
> get the 2.1.x branch back up to snuff. Sorry that's been slow coming  
> (no pun intended) but I'm starting to get caught up WRT SVN syncing  
> now, so hopefully tomorrow will be the day.
>
> As far as supporting 3 codelines, my own thought is to keep 2.0.x on  
> life support long enough to get a GA release of 2.1 out (and maybe a  
> little longer, I don't know what's really feasible here), but not to  
> spend too much time spit-shining 2.0.x anymore. If we can find a way  
> to fix the most broken features without bringing down the rest of  
> that house of cards, then that'll be good enough for me.
>
> Brett, Christian, I think JIRA voting is a great way to "weight" the  
> survey results with the users' priorities, but I want to make sure  
> we have an alternate mechanism that allows us to talk about features  
> - which will be sets of JIRA issues, in reality - outside of an  
> issue-tracking context. We need to use Confluence for this sort of  
> work, writing proposals that can be reviewed and voted on, IMO. I  
> was just thinking that Dennis' use of the survey system was a great  
> idea, and could be a perfect fit for this sort of planning.
>
> -john

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Dennis Lundberg-2]

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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Arnaud HERITIER]

+1

Arnaud

On Tue, Aug 26, 2008 at 8:33 PM, Dennis Lundberg <dennisl@...> 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: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
..........................................................
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
...........................................................

[John Casey-5]

I've renamed the current RC to 2.1.0-M1-RC12-SNAPSHOT, for this reason.
If we can put together a plan for the GA release of 2.1.0, I'd prefer to
have that in place before we do a final release from this RC branch.
Preferably something we can achieve in the next <2 months given current
resource availability.

I'd also like to see about doing some minimal release for 2.0.10 very
soon now, and putting 2.0.x in end-of-life asap once we have 2.1.0 out.

Ralph Goers wrote:

> 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@...
>

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...