commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] Re: Release managing a major version [and Lang 3.0 post mortem]
Date Fri, 29 Jul 2011 15:16:39 GMT
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,

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

> best regards,
> Luc

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message