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

[Marco Pesenti Gritti]

On Sun, Jun 22, 2008 at 3:34 AM, Eben Eliason <eben.eliason at gmail.com> wrote:
> 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?

Make sense. Wonder why Michael has been using the rel- prefix?

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

I agree, I think we should just get rid of update.x.

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

Make sense to me.

Marco