What about getting 0.12 released this year, still? I think we can
eventually reach this goal, with multirepos nearing completion and i18n
being in a "not so bad" shape.
As discussed with Remy on IRC, we should now start to think about a
feature freeze and reduce drastically the number of tickets that can
realistically be finished for 0.12. We still have plenty of opened
tickets for 0.12, but as usual we will mercilessly move the non-critical
ones to some later milestone, like 0.12.1 for bugs and 0.13 for
enhancements (*). Also, I've started to add the "needmajor" keyword on
tickets which need some API breakage in order to be completed, meaning
they should be done for 0.12 *or* will have to wait for 0.13 or later.
So, with the above in mind, I'd like to make "official" the schedule
that Remy proposed (well, the one I remember, as the IRC archive is down
atm):
- mid of October: merge multirepos
- end of October / early November: release 0.12beta1
- November: bug fixes, last few features
- Early December: 0.12rc1
- mid or end of December: 0.12
0.11.6 could be released in parallel ("when ready"), but November sounds
right.
-- Christian
(*) before that'll happen, maybe move 0.12.1 tickets to 0.12-stable and
0.13 ones to 0.1x, for minimizing the later moves. Indeed, in the recent
past, some tickets got moved from 0.11 to 0.11.1, and from there to
every other 0.11.(i+1); let's avoid this for 0.12 by putting them on
0.12-stable and *pulling* from there for the next 0.12.i release.
Yes, oh yes, please ;-)
> we should now start to think about a
> feature freeze and reduce drastically the number of tickets that can
> realistically be finished for 0.12. We still have plenty of opened
> tickets for 0.12, but as usual we will mercilessly move the non-critical
> ones to some later milestone, like 0.12.1 for bugs and 0.13 for
> enhancements (*). Also, I've started to add the "needmajor" keyword on
> tickets which need some API breakage in order to be completed, meaning
> they should be done for 0.12 *or* will have to wait for 0.13 or later.
All excellent initiatives.
> (*) before that'll happen, maybe move 0.12.1 tickets to 0.12-stable and
> 0.13 ones to 0.1x, for minimizing the later moves.
Also an excellent idea. Maybe call the next major milestone "trunk" or
"next-major", so as to remove all "numbered" references. Actually, what
about using more descriptive names all around:
0.12.1 -> 0.12-stable
0.13 -> next-major
1.0 -> idea-pool
2.0 -> alien-tech :-)
That should avoid having to explain the meaning of the various
milestones repeatedly.
Thanks for all your efforts!
-- Remy
I'd like to go with:
- next-major-0.1X
- next-minor-0.12.x
> 1.0 -> idea-pool
> 2.0 -> alien-tech :-)
>
Well, the meaning of 1.0 and 2.0 is well established I think, no need to
change them.
-- Christian
Sounds good. Any chance that you could create / rename the milestones
soon? I am on holidays next week, so I should have plenty of time for
working on Trac. I would like to do some triaging this week, so that I
don't run out of tickets ;-)
-- Remy
Done. So the idea is that right after the 0.12 release, we'll create new
0.12.1 and 0.13 milestones, *empty ones*, and we will selectively
retarget tickets from next-minor-0.12.x and next-major-0.1X milestones
to these new ones.
I believe this will minimize the massive ticket migrations we did in the
past when carrying over the bulk of reminding tickets from one milestone
to the next, and it will also help to keep the milestones more focused
on what's actually been developed or planned to be developed.
> I am on holidays next week, so I should have plenty of time for
> working on Trac. I would like to do some triaging this week, so that I
> don't run out of tickets ;-)
>
Great! Happy hacking ;-)
-- Christian