[darcs-users] milestones on issue tracker (plus a bit of roundup)

Eric Kow kowey at darcs.net
Wed Jun 16 14:30:53 UTC 2010

> "Eric Y. Kow" <kowey at darcs.net> writes:
> > PS. I've also cut the 2.5 branch early so that I can experiment with the
> >     new infrastructure I promised.  It now sets the resolvedin field to
> >     2.5.0 when you push to that branch.
> Is there a way to create an alias, so that a HEAD alias-milestone would
> point to say 2.6 now, and when 2.6 is branched to 2.7 and so on?

That would be tricky for me to do with my present knowledge, although
somebody who knows more about roundup (if there is a sane way to have
some sort of foo0 object which is an alias for some arbitrary foo42)
could chime in .

We could conceivably simulate it with scripting, but I would advise
against such a solution and it's potentially fragile.

> Just for the purpose of setting things more easily and with less
> thinking, presumably. Or maybe just name them like 2.4 STABLE, 2.5
> CURRENT, 2.6 HEAD? Later we have 2.4 STABLE, 2.5 STABLE, 2.6 CURRENT
> and 2.7 HEAD (maybe with an intermezzo with no CURRENT, but still 2.6
> HEAD?).

OK, four thoughts...

Zeroth, Renaming milestone objects is trivial (minor caveat is that
the roundup integration scripts refer to milestones by textual name
not milestone object number, so you have to update your posthooks by

First, tacking on these sorts of suffixes to versions sounds like a good
idea for clarity (right now the set has CURRENT, but STABLE and HEAD
seem nice), and the all caps no parens seems more aesthetically
pleasing than '(current)'.

Second, we should probably have a good story for point releases.
Dumping everything into Target-2.4 was a mistake (unconsciously
motivated on my part by a desire to avoid keyword proliferation).
Of course, we only manage one point release at a time, so there's little
risk of confusion; but researching the history of issues in the tracker
then becomes harder after the fact.  I think your proposal attractive
if we just tack point numbers on them.  Pre-2.5 ones would just be
2.4.x STABLE because we don't have time to track things down further,
(although if somebody wants to do it...).  The active milestones would
be 2.5.0 CURRENT and 2.6.0 HEAD.

Third, I'm not sure how to make things clear/consistent/robust on
release time, input needed.  I think what it might look like is

 - Now: Patches applied to the main repo could update the tracker to say
   they are resolved in 2.6.0 HEAD (milestone3)
 - Now: Patches applied to branch-2.5 cause the resolvedin field to
   change from 2.6.0 HEAD to 2.5.0 CURRENT

 - Immediately after 2.5.0 is released: The object
   http://bugs.darcs.net/milestone2 is renamed from "2.5.0 CURRENT"
   to "2.5.0 STABLE"
 - If we decide we need to create a 2.5.1 point release, we create
   a new milestone object named 2.5.1 CURRENT and update the branch-2.5
   posthook accordingly.

 - When we cut the 2.6.0 branch (here's the tricky bit), we create a
   new milestone object named 2.6.0 CURRENT and rename the 2.6.0 HEAD
   object (http://bugs.darcs.net/milestone3) to 2.7.0 HEAD.

Phew! That looks harder than it actually is.  Green light to implement?

Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20100616/bb3174df/attachment.pgp>

More information about the darcs-users mailing list