[Techteam] Adding a "Next release" milestone in trac

[Eben Eliason]

On Sat, Jun 21, 2008 at 9:07 PM, Marco Pesenti Gritti
<mpgritti at gmail.com> wrote:
> On Sat, Jun 21, 2008 at 6:12 AM, Michael Stone <michael at laptop.org> wrote:
>>> So if someone puts 'Groups' into Milestone 9.1.0; you might also tag
>>> it with rel-9.1.0:? because it is undefined and therefore not clear
>>> that can make that milestone without a lot more attention. As it gets
>>> broken down into smaller parts, some of those features might get
>>> rel-9.1.0:+ and some get -.
>>
>> Just so.

I would recommend minimizing the amount of syntax required for tagging:

9.1.0
9.1.0:?
9.1.0:+
9.1.0:-

seems sufficient to me.  Thoughts?

> There seem to be agreement about this, who do need to ask to create
> the milestone?
> I guess it should be "Update.3 (9.1.0)", following the current naming
> convention.

I don't see any benefit, personally, in dragging the "update.x"
nomenclature forward.  It oversimplifies release versions in the same
way that monotonically increasing integers oversimplify activity
versions.  The more precise we can be about the way we name things the
better off we'll be, especially if the tagging scheme depends on this
agreed upon naming.

Should we also clear out old milestones once they have been passed?
Once a milestone has passed, we should take it upon ourselves to
re-triage any tickets left in it, at which point it could simply
disappear.

Another alternative, which might actually prove better in the long
run, would be to name the milestones 8.2 and 9.0 (or 8.2.x and 9.0.x),
such that their scope is slightly more general, thus allowing the
tagging scheme to manage the least-significant version number.  In
this manner, after releasing 8.2.0, we can simply re-tag any bugs in
that milestone which we expect to go out in future bugfix releases as
8.2.1 etc. (leaving them in the 8.2.x milestone), or push them out
further to 9.0.x milestone instead.

- Eben