[Dev] Milestone numbering going forward

[Philippe Bossut]

Heikki Toivonen wrote:

>The trunk broke the first day we opened it for development, and it is
>still broken. We have no idea when it will be fixed. We took pretty
>massive changes in the first day.
>
>Things that we know of: There's wx build issues in the full build (so we
>cannot produce any new changes in wx until that is fixed). Import
>performance (at least) became three to ten times slower on Windows, and
>I have a suspicion many other cases with large calendar suffered as well
>on Windows. Unfortunately we don't know of any others beyond the import
>test, since running the performance tests now takes so long that nobody
>wants to do it on Windows and additionally the QA Lab Windows machine
>dies when running these perf tests (most likely a hardware issue).
>
>This is a pretty extreme situation we are in now, but there have been
>cases in the past where we have a thing or two broken almost all the
>time, while usually any single major issue gets fixed within a week or so.
>
>That is just to say that it will take us time to spin up a milestone. At
>a minimum I think it will take a week from trunk which is under heavy
>development, but possibly a little longer. Maybe that is ok for the
>general milestone.
>
>However, I am concerned what happens if someone reports a critical
>security issue with Chandler. A week or a little longer sounds bad to
>just fix the known issues and get to usable release, when we'd need to
>scramble with the security fix as well. And who knows what new security
>bugs we've already introduced into the trunk. The safe bet here would be
>to release the security fix from the branch. But we could also take the
>view that we are still too early to be this sophisticated and just get
>an update from the trunk.
>
All good points and I agree with every single one of them. I'm not 
advocating that we maintain the trunk stable at any time so that we can 
spin an update (especially a security update) at the drop of a hat. It 
is perfectly licit I think to create 0.6 updates from the last stable 
branch as long as the trunk is unstable (something we'll have to do 
tomorrow for instance if a major 0.6 issue would crop up).

My point is: if we think we will make development milestones the source 
of 0.6.x updates, then we should choose a (2-Forward) numbering scheme. 
Note that I also said that doing so will require more work from devs to 
stabilize the code base on a regular basis. It's more work for sure but 
it's also more useful feedback, more excited users, more new stuff out 
there more often...

Cheers,
- Philippe