> "Eric Y. Kow" <ko...@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 hand). 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
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
