You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2011/07/29 00:06:12 UTC
Release managing a major version [and Lang 3.0 post mortem]
Or:
"The Sisyphean task of shoving a large number of bytes up a big hill
while everyone else tries to add, remove and tweak said bytes".
= Step 1: Identify the issues.
Hopefully you are lucky and issues are accumulated in a JIRA, Bugzilla
or other issue tracker (here on JIRA as its our most common one). If
so - bonza. If not, then do your best to drive them to a single
location.
* Look in your code for TODO items that are bigger than minuscule
notes and move them to JIRA.
* Add the taglist plugin (if in Maven) so you can still point to the
minuscule items. Configure it.
* Look for any documentation or text files with todo items. Drive them to JIRA.
= Step 2: Triage the issues.
Any "Unscheduled" issue is grounds for triage. Triage involves moving
an issue, possibly via conversation, to the following items:
* Your current release target. Let's say 2.0.
* Subsequent release targets. In this case, 2.x.
* WONTFIX - ie) cast them back.
Use common sense - an issue _only_ affecting the 1.x branch should
have its own maintenance triage process. Other resolutions are fine
(Duplicate, Invalid, Can't Reproduce etc).
= Step 3: Start focusing on issues.
Initially it's fine to leave a huge clump of issues in 2.0. You're
casting wildly around, random work is happening and it's unlikely that
anything will be in 2.x. This is the new-development state. Lots of
discussion around APIs and scope of the project.
Your task is to keep things moving. Get things into the 2.0 list, plod
along working on just enough to keep the flywheel of interest going.
= Step 4: Recognize when it's time to start focusing on the finish
At some point you'll realize that the discussion is getting focused on
smaller details and not large issues. You'll also get users asking
when the release is coming. It's time to start winnowing down on the
remaining issues.
Primarily this means moving issues from 2.0 to 2.x. Do this for issues
that won't require a major version change later on. Minor bugs and
features that lack patches are good examples. Indicate that you're
moving them due to the lack of a patch - "Moving to 2.x as no patch".
It might mean making a 3.0 and moving issues there if they are a)
going to mean a major version release and b) there's no end in sight.
Obviously try to avoid that, but for wishlist items this is quite
likely. The reality is that if someone had the energy to implement the
wish, it would have happened.
By doing this you should have a tight list of issues to be worked on.
All very believable if the time is but applied. You might have some
major issues for which a solution is not apparent, but you can't
imagine releasing without a fix for.
= Step 5: Start driving for the finish
Focus on your 2.0 list. Keep pushing things to 2.x as much as possible
(unless a patch is available of course) and drive conversation to the
mailing list in a priority order (where priority is severity of bug
and the resolve-risk - ie) not having a solution).
Begin with your blocking issue with no solution. Get people talking
about it on the list. Don't be afraid to throw out half-arsed ideas.
Don't be afraid to nudge privately. Then start focusing on the
(hopefully) short list of other items.
Start to discuss the possibility of release. Consider a beta, it'll
allow you to release without all the items fixed, but will start to
drive people to think and believe in a release. It'll also test the
release mechanics.
Be increasingly defensive about new features or over-polishing.
= Step 6: Release, sweet release
Achieve goal. Conquer world etc.
-------
All of this is based on how Lang went (by and large). It does imply
that Lang went well; which it didn't imo. We took too long to accept
we should start a new major version [ie) JDK 5 is out, but it's not
standard so we won't even start]. We also treated it like a major
release, putting lots of features and bugfixes in as well as the non
backwards compatibile changes. Ideally we would have two versions, a
2.x branch and a 3.0 that launches quickly, and both have the same
bugfixes and features added to them.
Niall did a great job of backporting from 3.0 to 2.5 and then to 2.6.
That covered up a problem which shouldn't have existed, ie) changes
should have gone into both. The problem there, which largely requires
sweat and elbow grease to surmount is that backwards incompatible
changes are more likely to lead to source control merge conflicts [a
wild claim, but one that feels likely to my gut]. Ideally you would
auto-sync the changes to 2.x over to the 3.0 branch, but that means
being able to migrate them. The package name change is easy, but
generics would make that pretty hard.
What does this mean - it means we need to be working on 4.0 now (Java
7 compatible) while still developing the 3.x (Java 5 compatible)
branch. I think this should be easier to do; a search and replace on
'lang3' to 'lang4' and then attempt to auto-commit.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Release managing a major version [and Lang 3.0 post
mortem]
Posted by Phil Steitz <ph...@gmail.com>.
On 7/29/11 12:11 AM, Luc Maisonobe wrote:
> Hey guys, I guess we should have a thorough look at this process
> for our own 3.0 release.
>
> We are clearly late and we have a huge pile of unsorted issues.
> Many people open more and more requests while we try to solve
> them, as can be seen from Jira activity in the last few months.
>
> People start asking for 3.0 on the lists, and in fact many people
> asked me also off-list (and I guess this also happened to other
> developers).
>
> What do you think ? Are we ready to stabilize ? Can we schedule
> issues for 3.0, 3.x or 4.0 ? Can we solve issue faster than they
> are opened ?
Thanks, Hen for the thoughtful writeup and Luc for starting the
discussion for [math]. I think a lot of what Hen recounts is
relevant to [math] 3.0 and while I agree with Gilles that we are by
no means ready to cut a release, we are certainly ready to start
talking about a plan. I will volunteer to play Sisyphus for this
one, unless someone else is dying to, or we decide to cut a 2.2.1
and we nobody else wants to RM that. Here is what I will propose as
50,000 foot plan:
0) Do Hen's steps 1, 2, 3 with an eye toward preparing for step 4,
where we determine which open issues really require API changes,
prioritizing those for inclusion in 3.0. Gilles is correct that
there are some "unstable" API areas that we need to decide on for
3.0. We should first agree on what those are and start - and finish
- focused discussions on each of them, sarting on the list, then
refactoring executed in manageable-sized JIRAs. We should also not
be afraid to bring out some ugliness that we haven't addressed yet.
I think this is the hardest and most important thing to address for
3.0 - how exactly the public API is going to change.
Implementation ugliness, performance improvements, nice-to-have
features, etc. can all be added in 3.x.y. What we have to be
careful about is the API.
1) Do Hen's step 4, which essentially amounts to a release plan. At
this stage, we should also decide whether or not to plan and execute
a 2.2.1. I think it is best to postpone that decision until we have
a clear picture of both API changes and bugfixes slated for
inclusion in 3.0. We also need an inventory of what bugfixes have
been applied to trunk that could be backported[1]. Painful as it
may be, Hen's advice that pushing even some bugfixes out to 3.x in
favor of getting the API right and getting the release out is smart,
IMO.
2) Consider a release branch. In 1), we will have decided to push
some new features and possibly bug fixes into 3.x. We don't want to
slow down or discourage the great contributions that we have been
getting recently, so it is probably best to allow new work to
continue in either trunk (assuming we branch for the release) or in
a 3.1 branch.
I would recommend that we do these steps in order - i.e., don't
decide on 2.2.1 or no and branch or no just yet. First do step 0).
Phil
>
> best regards,
> Luc
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Release managing a major version [and Lang 3.0 post
mortem]
Posted by Phil Steitz <ph...@gmail.com>.
On 8/10/11 12:48 AM, Jörg Schaible wrote:
> Phil Steitz wrote:
>
>> On 8/9/11 4:05 PM, Phil Steitz wrote:
>>> Thanks for the nudge. I'll bite. Of course anyone is welcome to
>>> browse the open JIRA issues with 3.0 as fix version and add comments
>>> :)
>> I started slugging through JIRA. Made it all the way through the
>> unclassified list and will finish the first pass through the 3.0
>> issues tomorrow. I created a 3.1 version to push stuff into that
>> can be done without worrying about 3.0-compatibility.
> Another strategy I've used with success is a "3.x Maintenance" version as a
> placeholder for anything that can be resolved as part of a 3.x release. When
> you resolve an issue, you can set the proper version and anything that is
> post-phoned does not have to be touched when cutting the release ... ;-)
Yeah, that is pretty much what I meant by 3.1, with the following
additional "meaning"
3.0 - must fix for 3.0 release == bad bugs, things virtually
finished, API changes we are comfortable with
3.1 - not showstopper bugs, enhancements not started or not far
enough along, API improvements that can be done compatibly
4.0 (nothing there yet) - API changes that will not be doable
compatibly in 3.x but we are not ready to do them for 3.0
Phil
>
> [snip]
>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Release managing a major version [and Lang 3.0 post mortem]
Posted by Jörg Schaible <jo...@scalaris.com>.
Phil Steitz wrote:
> On 8/9/11 4:05 PM, Phil Steitz wrote:
>> Thanks for the nudge. I'll bite. Of course anyone is welcome to
>> browse the open JIRA issues with 3.0 as fix version and add comments
>> :)
>
> I started slugging through JIRA. Made it all the way through the
> unclassified list and will finish the first pass through the 3.0
> issues tomorrow. I created a 3.1 version to push stuff into that
> can be done without worrying about 3.0-compatibility.
Another strategy I've used with success is a "3.x Maintenance" version as a
placeholder for anything that can be resolved as part of a 3.x release. When
you resolve an issue, you can set the proper version and anything that is
post-phoned does not have to be touched when cutting the release ... ;-)
[snip]
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Release managing a major version [and Lang 3.0 post
mortem]
Posted by Phil Steitz <ph...@gmail.com>.
On 8/9/11 4:05 PM, Phil Steitz wrote:
> Thanks for the nudge. I'll bite. Of course anyone is welcome to
> browse the open JIRA issues with 3.0 as fix version and add comments
> :)
I started slugging through JIRA. Made it all the way through the
unclassified list and will finish the first pass through the 3.0
issues tomorrow. I created a 3.1 version to push stuff into that
can be done without worrying about 3.0-compatibility. There are a
few issues left in "unclassified" (no fix version), all of which I
recommend WONT_FIX. Please all feel free to chime in on what can /
cannot be moved out and what should be WONT_FIX.
I assigned a few issues to myself, partly just to make sure that I
get to them "RSN." I rarely do this and never mean to discourage
others from submitting patches against the issues that I have
"claimed." In fact, most of the issues that I assigned to myself
have patches contributed by other people and improvements to any /
all patches are most welcome. One other thing that I noticed is
that some contributors are forgetting to check the little "Intended
for contribution" box when submitting patches via JIRA. We need to
have those little boxes checked, so it would be great if people
could make sure to remember that and, if possible, go back and clean
up the missing ones.
Once I finish the first pass I will try to pull together a list of
key design decisions that we need to make, referencing the issues
where they arisen. Then a release plan. Thanks in advance for help
and patience.
Phil
>
> Phil
>
> On Tue, Aug 9, 2011 at 2:59 PM, Greg Sterijevski <gs...@gmail.com> wrote:
>> Does anyone have a list of showstopper bugs and features. If we want a 3.0
>> release soon, then perhaps some kind of a prioritized list would help us in
>> the community concentrate some of our efforts? I was thinking that the
>> individuals with commit privileges could put this together since they are
>> probably most acutely aware of where things stand. Once that list is
>> published, each of us in the community could commit to a task or two.
>>
>>
>> -Greg
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Release managing a major version [and Lang 3.0 post mortem]
Posted by Henri Yandell <fl...@gmail.com>.
Heh - s/criticism/encouragement :)
On Tue, Aug 9, 2011 at 5:45 PM, Greg Sterijevski <gs...@gmail.com> wrote:
> Yes, criticism well made. However, in solving the voting problem, the fewer
> the voters and the fewer the choices, the quicker that a solution can be
> determined. The worry is that 1000 people pull in 1000 directions, as
> opposed to 10 people pulling in 6 directions. ;-)
>
>
>
> On Tue, Aug 9, 2011 at 7:07 PM, Henri Yandell <fl...@gmail.com> wrote:
>
>> Btw (aimed to Greg and anyone else) - never feel that the committers
>> would be best to put it together. I've gotten Open Source projects out
>> the door without being a committer simply by listing the things I/they
>> thought they should work on on a wiki. It's a bit more of a pain
>> without access to define versions in the issue tracker, but very
>> doable.
>>
>> For example - look at the list of JIRA issues and add your thoughts on
>> whether it should or should not be in the next version. You'll be
>> amazed (I hope) at how you can galvanize activity.
>>
>> Hen
>>
>> On Tue, Aug 9, 2011 at 4:05 PM, Phil Steitz <ph...@gmail.com> wrote:
>> > Thanks for the nudge. I'll bite. Of course anyone is welcome to
>> > browse the open JIRA issues with 3.0 as fix version and add comments
>> > :)
>> >
>> > Phil
>> >
>> > On Tue, Aug 9, 2011 at 2:59 PM, Greg Sterijevski <gs...@gmail.com>
>> wrote:
>> >> Does anyone have a list of showstopper bugs and features. If we want a
>> 3.0
>> >> release soon, then perhaps some kind of a prioritized list would help us
>> in
>> >> the community concentrate some of our efforts? I was thinking that the
>> >> individuals with commit privileges could put this together since they
>> are
>> >> probably most acutely aware of where things stand. Once that list is
>> >> published, each of us in the community could commit to a task or two.
>> >>
>> >>
>> >> -Greg
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Release managing a major version [and Lang 3.0 post mortem]
Posted by Greg Sterijevski <gs...@gmail.com>.
Yes, criticism well made. However, in solving the voting problem, the fewer
the voters and the fewer the choices, the quicker that a solution can be
determined. The worry is that 1000 people pull in 1000 directions, as
opposed to 10 people pulling in 6 directions. ;-)
On Tue, Aug 9, 2011 at 7:07 PM, Henri Yandell <fl...@gmail.com> wrote:
> Btw (aimed to Greg and anyone else) - never feel that the committers
> would be best to put it together. I've gotten Open Source projects out
> the door without being a committer simply by listing the things I/they
> thought they should work on on a wiki. It's a bit more of a pain
> without access to define versions in the issue tracker, but very
> doable.
>
> For example - look at the list of JIRA issues and add your thoughts on
> whether it should or should not be in the next version. You'll be
> amazed (I hope) at how you can galvanize activity.
>
> Hen
>
> On Tue, Aug 9, 2011 at 4:05 PM, Phil Steitz <ph...@gmail.com> wrote:
> > Thanks for the nudge. I'll bite. Of course anyone is welcome to
> > browse the open JIRA issues with 3.0 as fix version and add comments
> > :)
> >
> > Phil
> >
> > On Tue, Aug 9, 2011 at 2:59 PM, Greg Sterijevski <gs...@gmail.com>
> wrote:
> >> Does anyone have a list of showstopper bugs and features. If we want a
> 3.0
> >> release soon, then perhaps some kind of a prioritized list would help us
> in
> >> the community concentrate some of our efforts? I was thinking that the
> >> individuals with commit privileges could put this together since they
> are
> >> probably most acutely aware of where things stand. Once that list is
> >> published, each of us in the community could commit to a task or two.
> >>
> >>
> >> -Greg
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [math] Re: Release managing a major version [and Lang 3.0 post mortem]
Posted by Henri Yandell <fl...@gmail.com>.
Btw (aimed to Greg and anyone else) - never feel that the committers
would be best to put it together. I've gotten Open Source projects out
the door without being a committer simply by listing the things I/they
thought they should work on on a wiki. It's a bit more of a pain
without access to define versions in the issue tracker, but very
doable.
For example - look at the list of JIRA issues and add your thoughts on
whether it should or should not be in the next version. You'll be
amazed (I hope) at how you can galvanize activity.
Hen
On Tue, Aug 9, 2011 at 4:05 PM, Phil Steitz <ph...@gmail.com> wrote:
> Thanks for the nudge. I'll bite. Of course anyone is welcome to
> browse the open JIRA issues with 3.0 as fix version and add comments
> :)
>
> Phil
>
> On Tue, Aug 9, 2011 at 2:59 PM, Greg Sterijevski <gs...@gmail.com> wrote:
>> Does anyone have a list of showstopper bugs and features. If we want a 3.0
>> release soon, then perhaps some kind of a prioritized list would help us in
>> the community concentrate some of our efforts? I was thinking that the
>> individuals with commit privileges could put this together since they are
>> probably most acutely aware of where things stand. Once that list is
>> published, each of us in the community could commit to a task or two.
>>
>>
>> -Greg
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Release managing a major version [and Lang 3.0 post mortem]
Posted by Phil Steitz <ph...@gmail.com>.
Thanks for the nudge. I'll bite. Of course anyone is welcome to
browse the open JIRA issues with 3.0 as fix version and add comments
:)
Phil
On Tue, Aug 9, 2011 at 2:59 PM, Greg Sterijevski <gs...@gmail.com> wrote:
> Does anyone have a list of showstopper bugs and features. If we want a 3.0
> release soon, then perhaps some kind of a prioritized list would help us in
> the community concentrate some of our efforts? I was thinking that the
> individuals with commit privileges could put this together since they are
> probably most acutely aware of where things stand. Once that list is
> published, each of us in the community could commit to a task or two.
>
>
> -Greg
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Release managing a major version [and Lang 3.0 post mortem]
Posted by Matt Benson <gu...@gmail.com>.
Probably more my own mistake than yours. :)
Regards,
Matt
On Tue, Aug 9, 2011 at 5:50 PM, Greg Sterijevski <gs...@gmail.com> wrote:
> My bad! This was indeed for math commons...
>
> On Tue, Aug 9, 2011 at 5:02 PM, Matt Benson <gu...@gmail.com> wrote:
>>
>> 3.0 came out a couple of weeks ago. :) 3.0.1 is on the way now.
>>
>> Matt
>>
>> On Tue, Aug 9, 2011 at 4:59 PM, Greg Sterijevski <gs...@gmail.com>
>> wrote:
>> > Does anyone have a list of showstopper bugs and features. If we want a
>> > 3.0
>> > release soon, then perhaps some kind of a prioritized list would help us
>> > in
>> > the community concentrate some of our efforts? I was thinking that the
>> > individuals with commit privileges could put this together since they
>> > are
>> > probably most acutely aware of where things stand. Once that list is
>> > published, each of us in the community could commit to a task or two.
>> >
>> >
>> > -Greg
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Release managing a major version [and Lang 3.0 post mortem]
Posted by Greg Sterijevski <gs...@gmail.com>.
My bad! This was indeed for math commons...
On Tue, Aug 9, 2011 at 5:02 PM, Matt Benson <gu...@gmail.com> wrote:
> 3.0 came out a couple of weeks ago. :) 3.0.1 is on the way now.
>
> Matt
>
> On Tue, Aug 9, 2011 at 4:59 PM, Greg Sterijevski <gs...@gmail.com>
> wrote:
> > Does anyone have a list of showstopper bugs and features. If we want a
> 3.0
> > release soon, then perhaps some kind of a prioritized list would help us
> in
> > the community concentrate some of our efforts? I was thinking that the
> > individuals with commit privileges could put this together since they are
> > probably most acutely aware of where things stand. Once that list is
> > published, each of us in the community could commit to a task or two.
> >
> >
> > -Greg
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [math] Re: Release managing a major version [and Lang 3.0 post mortem]
Posted by Matt Benson <gu...@gmail.com>.
3.0 came out a couple of weeks ago. :) 3.0.1 is on the way now.
Matt
On Tue, Aug 9, 2011 at 4:59 PM, Greg Sterijevski <gs...@gmail.com> wrote:
> Does anyone have a list of showstopper bugs and features. If we want a 3.0
> release soon, then perhaps some kind of a prioritized list would help us in
> the community concentrate some of our efforts? I was thinking that the
> individuals with commit privileges could put this together since they are
> probably most acutely aware of where things stand. Once that list is
> published, each of us in the community could commit to a task or two.
>
>
> -Greg
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Release managing a major version [and Lang 3.0 post mortem]
Posted by Greg Sterijevski <gs...@gmail.com>.
Does anyone have a list of showstopper bugs and features. If we want a 3.0
release soon, then perhaps some kind of a prioritized list would help us in
the community concentrate some of our efforts? I was thinking that the
individuals with commit privileges could put this together since they are
probably most acutely aware of where things stand. Once that list is
published, each of us in the community could commit to a task or two.
-Greg
Re: [math] Re: Release managing a major version [and Lang 3.0 post
mortem]
Posted by Phil Steitz <ph...@gmail.com>.
On 7/29/11 8:11 AM, Gary Gregory wrote:
> If you are trying to get a 3.0 release out ASAP, you just need to
> address showstopper bugs.
>
> If a new package is too new and shiny to put out and not fully baked,
> consider taking it out of 3.0. Radical but simple.
The problem with that is that we have significant API refactoring in
progress. This is not just a matter of new packages.
>
> The exceptions issue is tricky you want to have something stable for
> future releases unless you do not care about compatibility.
Exceptions are one area where we have incompatible change planned.
There are others as well. We *do* care about compatibility and do
not want to push out a series of incompatible, package-renamed
releases as we stabilize the API. So we have to settle the API
issues prior to 3.0 release. I think it is fair to say that the
[math] API has improved with each major release and I think that
applies to what is in trunk now vis a vis 2.x. We have learned a
lot since the 1.x days, but some of the APIs have not yet taken
advantage of that learning. I would like to see us get a big slug
of it at least done in 3.0, so we can focus more on features,
functionality and performance in 3.x releases rather than struggling
to maintain compatibility or getting distracted immediately with 4.0
discussions.
Phil
>
> In general, it may be useful to think of giving each release a theme
> to help you sort issues.
>
> Gary
>
> On Fri, Jul 29, 2011 at 7:02 AM, Gilles Sadowski
> <gi...@harfang.homelinux.org> wrote:
>> Hello.
>>
>>> Hey guys, I guess we should have a thorough look at this process
>>> for our own 3.0 release.
>>>
>>> We are clearly late and we have a huge pile of unsorted issues. Many
>>> people open more and more requests while we try to solve them, as
>>> can be seen from Jira activity in the last few months.
>>>
>>> People start asking for 3.0 on the lists, and in fact many people
>>> asked me also off-list (and I guess this also happened to other
>>> developers).
>>>
>>> What do you think ?
>>> Are we ready to stabilize ?
>> IMHO, no.
>> For example, whole new packages have been added too recently to consider
>> that they are stable. Also old ones have been either modified back and forth
>> (e.g. moving exception classes) or should/could be renamed in order to
>> better reflect their purpose or contents (e.g. "optimization.general").
>>
>> But that should not prevent a release! :-)
>>
>>> Can we schedule
>>> issues for 3.0, 3.x or 4.0 ?
>> My preference is to resolve satisfactorily (or temporarily) older issues
>> first (e.g. the exceptions issue, of course...).
>> Then, outstanding bugs (e.g. in "RegulaFalsiSolver") should have top
>> priority.
>> The sorting based on "patch/no patch" proposed in the quoted mail is a good
>> idea.
>>
>>> Can we solve issue faster than they are
>>> opened ?
>> ;-)
>>
>> Regards,
>> Gilles
>>
>>> Le 29/07/2011 00:06, Henri Yandell a écrit :
>>>> Or:
>>>>
>>>> "The Sisyphean task of shoving a large number of bytes up a big hill
>>>> while everyone else tries to add, remove and tweak said bytes".
>>>>
>>>> = Step 1: Identify the issues.
>>>>
>>>> Hopefully you are lucky and issues are accumulated in a JIRA, Bugzilla
>>>> or other issue tracker (here on JIRA as its our most common one). If
>>>> so - bonza. If not, then do your best to drive them to a single
>>>> location.
>>>>
>>>> * Look in your code for TODO items that are bigger than minuscule
>>>> notes and move them to JIRA.
>>>> * Add the taglist plugin (if in Maven) so you can still point to the
>>>> minuscule items. Configure it.
>>>> * Look for any documentation or text files with todo items. Drive them to JIRA.
>>>>
>>>> = Step 2: Triage the issues.
>>>>
>>>> Any "Unscheduled" issue is grounds for triage. Triage involves moving
>>>> an issue, possibly via conversation, to the following items:
>>>>
>>>> * Your current release target. Let's say 2.0.
>>>> * Subsequent release targets. In this case, 2.x.
>>>> * WONTFIX - ie) cast them back.
>>>>
>>>> Use common sense - an issue _only_ affecting the 1.x branch should
>>>> have its own maintenance triage process. Other resolutions are fine
>>>> (Duplicate, Invalid, Can't Reproduce etc).
>>>>
>>>> = Step 3: Start focusing on issues.
>>>>
>>>> Initially it's fine to leave a huge clump of issues in 2.0. You're
>>>> casting wildly around, random work is happening and it's unlikely that
>>>> anything will be in 2.x. This is the new-development state. Lots of
>>>> discussion around APIs and scope of the project.
>>>>
>>>> Your task is to keep things moving. Get things into the 2.0 list, plod
>>>> along working on just enough to keep the flywheel of interest going.
>>>>
>>>> = Step 4: Recognize when it's time to start focusing on the finish
>>>>
>>>> At some point you'll realize that the discussion is getting focused on
>>>> smaller details and not large issues. You'll also get users asking
>>>> when the release is coming. It's time to start winnowing down on the
>>>> remaining issues.
>>>>
>>>> Primarily this means moving issues from 2.0 to 2.x. Do this for issues
>>>> that won't require a major version change later on. Minor bugs and
>>>> features that lack patches are good examples. Indicate that you're
>>>> moving them due to the lack of a patch - "Moving to 2.x as no patch".
>>>>
>>>> It might mean making a 3.0 and moving issues there if they are a)
>>>> going to mean a major version release and b) there's no end in sight.
>>>> Obviously try to avoid that, but for wishlist items this is quite
>>>> likely. The reality is that if someone had the energy to implement the
>>>> wish, it would have happened.
>>>>
>>>> By doing this you should have a tight list of issues to be worked on.
>>>> All very believable if the time is but applied. You might have some
>>>> major issues for which a solution is not apparent, but you can't
>>>> imagine releasing without a fix for.
>>>>
>>>> = Step 5: Start driving for the finish
>>>>
>>>> Focus on your 2.0 list. Keep pushing things to 2.x as much as possible
>>>> (unless a patch is available of course) and drive conversation to the
>>>> mailing list in a priority order (where priority is severity of bug
>>>> and the resolve-risk - ie) not having a solution).
>>>>
>>>> Begin with your blocking issue with no solution. Get people talking
>>>> about it on the list. Don't be afraid to throw out half-arsed ideas.
>>>> Don't be afraid to nudge privately. Then start focusing on the
>>>> (hopefully) short list of other items.
>>>>
>>>> Start to discuss the possibility of release. Consider a beta, it'll
>>>> allow you to release without all the items fixed, but will start to
>>>> drive people to think and believe in a release. It'll also test the
>>>> release mechanics.
>>>>
>>>> Be increasingly defensive about new features or over-polishing.
>>>>
>>>> = Step 6: Release, sweet release
>>>>
>>>> Achieve goal. Conquer world etc.
>>>>
>>>> -------
>>>>
>>>> All of this is based on how Lang went (by and large). It does imply
>>>> that Lang went well; which it didn't imo. We took too long to accept
>>>> we should start a new major version [ie) JDK 5 is out, but it's not
>>>> standard so we won't even start]. We also treated it like a major
>>>> release, putting lots of features and bugfixes in as well as the non
>>>> backwards compatibile changes. Ideally we would have two versions, a
>>>> 2.x branch and a 3.0 that launches quickly, and both have the same
>>>> bugfixes and features added to them.
>>>>
>>>> Niall did a great job of backporting from 3.0 to 2.5 and then to 2.6.
>>>> That covered up a problem which shouldn't have existed, ie) changes
>>>> should have gone into both. The problem there, which largely requires
>>>> sweat and elbow grease to surmount is that backwards incompatible
>>>> changes are more likely to lead to source control merge conflicts [a
>>>> wild claim, but one that feels likely to my gut]. Ideally you would
>>>> auto-sync the changes to 2.x over to the 3.0 branch, but that means
>>>> being able to migrate them. The package name change is easy, but
>>>> generics would make that pretty hard.
>>>>
>>>> What does this mean - it means we need to be working on 4.0 now (Java
>>>> 7 compatible) while still developing the 3.x (Java 5 compatible)
>>>> branch. I think this should be easier to do; a search and replace on
>>>> 'lang3' to 'lang4' and then attempt to auto-commit.
>>>>
>>>> Hen
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Release managing a major version [and Lang 3.0 post mortem]
Posted by Gary Gregory <ga...@gmail.com>.
If you are trying to get a 3.0 release out ASAP, you just need to
address showstopper bugs.
If a new package is too new and shiny to put out and not fully baked,
consider taking it out of 3.0. Radical but simple.
The exceptions issue is tricky you want to have something stable for
future releases unless you do not care about compatibility.
In general, it may be useful to think of giving each release a theme
to help you sort issues.
Gary
On Fri, Jul 29, 2011 at 7:02 AM, Gilles Sadowski
<gi...@harfang.homelinux.org> wrote:
> Hello.
>
>> Hey guys, I guess we should have a thorough look at this process
>> for our own 3.0 release.
>>
>> We are clearly late and we have a huge pile of unsorted issues. Many
>> people open more and more requests while we try to solve them, as
>> can be seen from Jira activity in the last few months.
>>
>> People start asking for 3.0 on the lists, and in fact many people
>> asked me also off-list (and I guess this also happened to other
>> developers).
>>
>> What do you think ?
>
>> Are we ready to stabilize ?
>
> IMHO, no.
> For example, whole new packages have been added too recently to consider
> that they are stable. Also old ones have been either modified back and forth
> (e.g. moving exception classes) or should/could be renamed in order to
> better reflect their purpose or contents (e.g. "optimization.general").
>
> But that should not prevent a release! :-)
>
>> Can we schedule
>> issues for 3.0, 3.x or 4.0 ?
>
> My preference is to resolve satisfactorily (or temporarily) older issues
> first (e.g. the exceptions issue, of course...).
> Then, outstanding bugs (e.g. in "RegulaFalsiSolver") should have top
> priority.
> The sorting based on "patch/no patch" proposed in the quoted mail is a good
> idea.
>
>> Can we solve issue faster than they are
>> opened ?
>
> ;-)
>
> Regards,
> Gilles
>
>>
>> Le 29/07/2011 00:06, Henri Yandell a écrit :
>> >Or:
>> >
>> >"The Sisyphean task of shoving a large number of bytes up a big hill
>> >while everyone else tries to add, remove and tweak said bytes".
>> >
>> >= Step 1: Identify the issues.
>> >
>> >Hopefully you are lucky and issues are accumulated in a JIRA, Bugzilla
>> >or other issue tracker (here on JIRA as its our most common one). If
>> >so - bonza. If not, then do your best to drive them to a single
>> >location.
>> >
>> >* Look in your code for TODO items that are bigger than minuscule
>> >notes and move them to JIRA.
>> >* Add the taglist plugin (if in Maven) so you can still point to the
>> >minuscule items. Configure it.
>> >* Look for any documentation or text files with todo items. Drive them to JIRA.
>> >
>> >= Step 2: Triage the issues.
>> >
>> >Any "Unscheduled" issue is grounds for triage. Triage involves moving
>> >an issue, possibly via conversation, to the following items:
>> >
>> >* Your current release target. Let's say 2.0.
>> >* Subsequent release targets. In this case, 2.x.
>> >* WONTFIX - ie) cast them back.
>> >
>> >Use common sense - an issue _only_ affecting the 1.x branch should
>> >have its own maintenance triage process. Other resolutions are fine
>> >(Duplicate, Invalid, Can't Reproduce etc).
>> >
>> >= Step 3: Start focusing on issues.
>> >
>> >Initially it's fine to leave a huge clump of issues in 2.0. You're
>> >casting wildly around, random work is happening and it's unlikely that
>> >anything will be in 2.x. This is the new-development state. Lots of
>> >discussion around APIs and scope of the project.
>> >
>> >Your task is to keep things moving. Get things into the 2.0 list, plod
>> >along working on just enough to keep the flywheel of interest going.
>> >
>> >= Step 4: Recognize when it's time to start focusing on the finish
>> >
>> >At some point you'll realize that the discussion is getting focused on
>> >smaller details and not large issues. You'll also get users asking
>> >when the release is coming. It's time to start winnowing down on the
>> >remaining issues.
>> >
>> >Primarily this means moving issues from 2.0 to 2.x. Do this for issues
>> >that won't require a major version change later on. Minor bugs and
>> >features that lack patches are good examples. Indicate that you're
>> >moving them due to the lack of a patch - "Moving to 2.x as no patch".
>> >
>> >It might mean making a 3.0 and moving issues there if they are a)
>> >going to mean a major version release and b) there's no end in sight.
>> >Obviously try to avoid that, but for wishlist items this is quite
>> >likely. The reality is that if someone had the energy to implement the
>> >wish, it would have happened.
>> >
>> >By doing this you should have a tight list of issues to be worked on.
>> >All very believable if the time is but applied. You might have some
>> >major issues for which a solution is not apparent, but you can't
>> >imagine releasing without a fix for.
>> >
>> >= Step 5: Start driving for the finish
>> >
>> >Focus on your 2.0 list. Keep pushing things to 2.x as much as possible
>> >(unless a patch is available of course) and drive conversation to the
>> >mailing list in a priority order (where priority is severity of bug
>> >and the resolve-risk - ie) not having a solution).
>> >
>> >Begin with your blocking issue with no solution. Get people talking
>> >about it on the list. Don't be afraid to throw out half-arsed ideas.
>> >Don't be afraid to nudge privately. Then start focusing on the
>> >(hopefully) short list of other items.
>> >
>> >Start to discuss the possibility of release. Consider a beta, it'll
>> >allow you to release without all the items fixed, but will start to
>> >drive people to think and believe in a release. It'll also test the
>> >release mechanics.
>> >
>> >Be increasingly defensive about new features or over-polishing.
>> >
>> >= Step 6: Release, sweet release
>> >
>> >Achieve goal. Conquer world etc.
>> >
>> >-------
>> >
>> >All of this is based on how Lang went (by and large). It does imply
>> >that Lang went well; which it didn't imo. We took too long to accept
>> >we should start a new major version [ie) JDK 5 is out, but it's not
>> >standard so we won't even start]. We also treated it like a major
>> >release, putting lots of features and bugfixes in as well as the non
>> >backwards compatibile changes. Ideally we would have two versions, a
>> >2.x branch and a 3.0 that launches quickly, and both have the same
>> >bugfixes and features added to them.
>> >
>> >Niall did a great job of backporting from 3.0 to 2.5 and then to 2.6.
>> >That covered up a problem which shouldn't have existed, ie) changes
>> >should have gone into both. The problem there, which largely requires
>> >sweat and elbow grease to surmount is that backwards incompatible
>> >changes are more likely to lead to source control merge conflicts [a
>> >wild claim, but one that feels likely to my gut]. Ideally you would
>> >auto-sync the changes to 2.x over to the 3.0 branch, but that means
>> >being able to migrate them. The package name change is easy, but
>> >generics would make that pretty hard.
>> >
>> >What does this mean - it means we need to be working on 4.0 now (Java
>> >7 compatible) while still developing the 3.x (Java 5 compatible)
>> >branch. I think this should be easier to do; a search and replace on
>> >'lang3' to 'lang4' and then attempt to auto-commit.
>> >
>> >Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Re: Release managing a major version [and Lang 3.0 post
mortem]
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> Hey guys, I guess we should have a thorough look at this process
> for our own 3.0 release.
>
> We are clearly late and we have a huge pile of unsorted issues. Many
> people open more and more requests while we try to solve them, as
> can be seen from Jira activity in the last few months.
>
> People start asking for 3.0 on the lists, and in fact many people
> asked me also off-list (and I guess this also happened to other
> developers).
>
> What do you think ?
> Are we ready to stabilize ?
IMHO, no.
For example, whole new packages have been added too recently to consider
that they are stable. Also old ones have been either modified back and forth
(e.g. moving exception classes) or should/could be renamed in order to
better reflect their purpose or contents (e.g. "optimization.general").
But that should not prevent a release! :-)
> Can we schedule
> issues for 3.0, 3.x or 4.0 ?
My preference is to resolve satisfactorily (or temporarily) older issues
first (e.g. the exceptions issue, of course...).
Then, outstanding bugs (e.g. in "RegulaFalsiSolver") should have top
priority.
The sorting based on "patch/no patch" proposed in the quoted mail is a good
idea.
> Can we solve issue faster than they are
> opened ?
;-)
Regards,
Gilles
>
> Le 29/07/2011 00:06, Henri Yandell a écrit :
> >Or:
> >
> >"The Sisyphean task of shoving a large number of bytes up a big hill
> >while everyone else tries to add, remove and tweak said bytes".
> >
> >= Step 1: Identify the issues.
> >
> >Hopefully you are lucky and issues are accumulated in a JIRA, Bugzilla
> >or other issue tracker (here on JIRA as its our most common one). If
> >so - bonza. If not, then do your best to drive them to a single
> >location.
> >
> >* Look in your code for TODO items that are bigger than minuscule
> >notes and move them to JIRA.
> >* Add the taglist plugin (if in Maven) so you can still point to the
> >minuscule items. Configure it.
> >* Look for any documentation or text files with todo items. Drive them to JIRA.
> >
> >= Step 2: Triage the issues.
> >
> >Any "Unscheduled" issue is grounds for triage. Triage involves moving
> >an issue, possibly via conversation, to the following items:
> >
> >* Your current release target. Let's say 2.0.
> >* Subsequent release targets. In this case, 2.x.
> >* WONTFIX - ie) cast them back.
> >
> >Use common sense - an issue _only_ affecting the 1.x branch should
> >have its own maintenance triage process. Other resolutions are fine
> >(Duplicate, Invalid, Can't Reproduce etc).
> >
> >= Step 3: Start focusing on issues.
> >
> >Initially it's fine to leave a huge clump of issues in 2.0. You're
> >casting wildly around, random work is happening and it's unlikely that
> >anything will be in 2.x. This is the new-development state. Lots of
> >discussion around APIs and scope of the project.
> >
> >Your task is to keep things moving. Get things into the 2.0 list, plod
> >along working on just enough to keep the flywheel of interest going.
> >
> >= Step 4: Recognize when it's time to start focusing on the finish
> >
> >At some point you'll realize that the discussion is getting focused on
> >smaller details and not large issues. You'll also get users asking
> >when the release is coming. It's time to start winnowing down on the
> >remaining issues.
> >
> >Primarily this means moving issues from 2.0 to 2.x. Do this for issues
> >that won't require a major version change later on. Minor bugs and
> >features that lack patches are good examples. Indicate that you're
> >moving them due to the lack of a patch - "Moving to 2.x as no patch".
> >
> >It might mean making a 3.0 and moving issues there if they are a)
> >going to mean a major version release and b) there's no end in sight.
> >Obviously try to avoid that, but for wishlist items this is quite
> >likely. The reality is that if someone had the energy to implement the
> >wish, it would have happened.
> >
> >By doing this you should have a tight list of issues to be worked on.
> >All very believable if the time is but applied. You might have some
> >major issues for which a solution is not apparent, but you can't
> >imagine releasing without a fix for.
> >
> >= Step 5: Start driving for the finish
> >
> >Focus on your 2.0 list. Keep pushing things to 2.x as much as possible
> >(unless a patch is available of course) and drive conversation to the
> >mailing list in a priority order (where priority is severity of bug
> >and the resolve-risk - ie) not having a solution).
> >
> >Begin with your blocking issue with no solution. Get people talking
> >about it on the list. Don't be afraid to throw out half-arsed ideas.
> >Don't be afraid to nudge privately. Then start focusing on the
> >(hopefully) short list of other items.
> >
> >Start to discuss the possibility of release. Consider a beta, it'll
> >allow you to release without all the items fixed, but will start to
> >drive people to think and believe in a release. It'll also test the
> >release mechanics.
> >
> >Be increasingly defensive about new features or over-polishing.
> >
> >= Step 6: Release, sweet release
> >
> >Achieve goal. Conquer world etc.
> >
> >-------
> >
> >All of this is based on how Lang went (by and large). It does imply
> >that Lang went well; which it didn't imo. We took too long to accept
> >we should start a new major version [ie) JDK 5 is out, but it's not
> >standard so we won't even start]. We also treated it like a major
> >release, putting lots of features and bugfixes in as well as the non
> >backwards compatibile changes. Ideally we would have two versions, a
> >2.x branch and a 3.0 that launches quickly, and both have the same
> >bugfixes and features added to them.
> >
> >Niall did a great job of backporting from 3.0 to 2.5 and then to 2.6.
> >That covered up a problem which shouldn't have existed, ie) changes
> >should have gone into both. The problem there, which largely requires
> >sweat and elbow grease to surmount is that backwards incompatible
> >changes are more likely to lead to source control merge conflicts [a
> >wild claim, but one that feels likely to my gut]. Ideally you would
> >auto-sync the changes to 2.x over to the 3.0 branch, but that means
> >being able to migrate them. The package name change is easy, but
> >generics would make that pretty hard.
> >
> >What does this mean - it means we need to be working on 4.0 now (Java
> >7 compatible) while still developing the 3.x (Java 5 compatible)
> >branch. I think this should be easier to do; a search and replace on
> >'lang3' to 'lang4' and then attempt to auto-commit.
> >
> >Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[math] Re: Release managing a major version [and Lang 3.0 post mortem]
Posted by Luc Maisonobe <Lu...@free.fr>.
Hey guys, I guess we should have a thorough look at this process
for our own 3.0 release.
We are clearly late and we have a huge pile of unsorted issues. Many
people open more and more requests while we try to solve them, as can be
seen from Jira activity in the last few months.
People start asking for 3.0 on the lists, and in fact many people asked
me also off-list (and I guess this also happened to other developers).
What do you think ? Are we ready to stabilize ? Can we schedule issues
for 3.0, 3.x or 4.0 ? Can we solve issue faster than they are opened ?
best regards,
Luc
Le 29/07/2011 00:06, Henri Yandell a écrit :
> Or:
>
> "The Sisyphean task of shoving a large number of bytes up a big hill
> while everyone else tries to add, remove and tweak said bytes".
>
> = Step 1: Identify the issues.
>
> Hopefully you are lucky and issues are accumulated in a JIRA, Bugzilla
> or other issue tracker (here on JIRA as its our most common one). If
> so - bonza. If not, then do your best to drive them to a single
> location.
>
> * Look in your code for TODO items that are bigger than minuscule
> notes and move them to JIRA.
> * Add the taglist plugin (if in Maven) so you can still point to the
> minuscule items. Configure it.
> * Look for any documentation or text files with todo items. Drive them to JIRA.
>
> = Step 2: Triage the issues.
>
> Any "Unscheduled" issue is grounds for triage. Triage involves moving
> an issue, possibly via conversation, to the following items:
>
> * Your current release target. Let's say 2.0.
> * Subsequent release targets. In this case, 2.x.
> * WONTFIX - ie) cast them back.
>
> Use common sense - an issue _only_ affecting the 1.x branch should
> have its own maintenance triage process. Other resolutions are fine
> (Duplicate, Invalid, Can't Reproduce etc).
>
> = Step 3: Start focusing on issues.
>
> Initially it's fine to leave a huge clump of issues in 2.0. You're
> casting wildly around, random work is happening and it's unlikely that
> anything will be in 2.x. This is the new-development state. Lots of
> discussion around APIs and scope of the project.
>
> Your task is to keep things moving. Get things into the 2.0 list, plod
> along working on just enough to keep the flywheel of interest going.
>
> = Step 4: Recognize when it's time to start focusing on the finish
>
> At some point you'll realize that the discussion is getting focused on
> smaller details and not large issues. You'll also get users asking
> when the release is coming. It's time to start winnowing down on the
> remaining issues.
>
> Primarily this means moving issues from 2.0 to 2.x. Do this for issues
> that won't require a major version change later on. Minor bugs and
> features that lack patches are good examples. Indicate that you're
> moving them due to the lack of a patch - "Moving to 2.x as no patch".
>
> It might mean making a 3.0 and moving issues there if they are a)
> going to mean a major version release and b) there's no end in sight.
> Obviously try to avoid that, but for wishlist items this is quite
> likely. The reality is that if someone had the energy to implement the
> wish, it would have happened.
>
> By doing this you should have a tight list of issues to be worked on.
> All very believable if the time is but applied. You might have some
> major issues for which a solution is not apparent, but you can't
> imagine releasing without a fix for.
>
> = Step 5: Start driving for the finish
>
> Focus on your 2.0 list. Keep pushing things to 2.x as much as possible
> (unless a patch is available of course) and drive conversation to the
> mailing list in a priority order (where priority is severity of bug
> and the resolve-risk - ie) not having a solution).
>
> Begin with your blocking issue with no solution. Get people talking
> about it on the list. Don't be afraid to throw out half-arsed ideas.
> Don't be afraid to nudge privately. Then start focusing on the
> (hopefully) short list of other items.
>
> Start to discuss the possibility of release. Consider a beta, it'll
> allow you to release without all the items fixed, but will start to
> drive people to think and believe in a release. It'll also test the
> release mechanics.
>
> Be increasingly defensive about new features or over-polishing.
>
> = Step 6: Release, sweet release
>
> Achieve goal. Conquer world etc.
>
> -------
>
> All of this is based on how Lang went (by and large). It does imply
> that Lang went well; which it didn't imo. We took too long to accept
> we should start a new major version [ie) JDK 5 is out, but it's not
> standard so we won't even start]. We also treated it like a major
> release, putting lots of features and bugfixes in as well as the non
> backwards compatibile changes. Ideally we would have two versions, a
> 2.x branch and a 3.0 that launches quickly, and both have the same
> bugfixes and features added to them.
>
> Niall did a great job of backporting from 3.0 to 2.5 and then to 2.6.
> That covered up a problem which shouldn't have existed, ie) changes
> should have gone into both. The problem there, which largely requires
> sweat and elbow grease to surmount is that backwards incompatible
> changes are more likely to lead to source control merge conflicts [a
> wild claim, but one that feels likely to my gut]. Ideally you would
> auto-sync the changes to 2.x over to the 3.0 branch, but that means
> being able to migrate them. The package name change is easy, but
> generics would make that pretty hard.
>
> What does this mean - it means we need to be working on 4.0 now (Java
> 7 compatible) while still developing the 3.x (Java 5 compatible)
> branch. I think this should be easier to do; a search and replace on
> 'lang3' to 'lang4' and then attempt to auto-commit.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org