Hi, Eric Kow <ko...@darcs.net> writes: > - 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. now, the rename bit looks a bit worrying. That would mean that we need to change all existing uses of 2.7.0 HEAD to 2.6.0 CURRENT, no? So what's the rationale to not just create new 2.7.0 and just rename 2.6.0 HEAD to 2.6.0 CURRENT? At the branch point, the CURRENT inherits all fixes that were made in HEAD up to that moment.
We just need to make sure that posthooks are updated on every milestone wibble. Hopefully, even if we don't do this immediately, no harm should happen as the milestones they refer to will have changed names in the meantime (2.6.0 HEAD would be 2.6.0 CURRENT, so HEAD won't accidentally mark things as resolved in 2.6.0 CURRENT post-branching...). Other than this, I think the process is good to implement. Yours, Petr. _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
