![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
Entry tags:
stable releases
This recent post brought to my attention the fact that it really ought to be simpler for sites using DW code in production to easily keep up with stable milestones of DW development, without having to look through all of our repositories for the most recent milestone tags. Besides, the milestone tags are tied to code pushes on dreamwidth.org and not necessarily an indication of stability!
I propose the following mechanism:
1. Add a "stable" tag to all of our shared repositories. We already do code freezes where we only put in changes to fix bugs that are uncovered immediately after a code push. When the code freeze is lifted, move the "stable" tag to the most recent milestone and leave it there until after the next push/freeze cycle. For example, the most recent cycle would have moved the stable tag from 0.21.2 to 1.0.1 once it became clear there would be no 1.0.2 needed.
2. Add a new site config parameter (something like DW_STABLE) that indicates whether a site is only accepting our "stable" changes.
3. Change the behavior of -update in bin/vcv to only update as far as the "stable" tag if DW_STABLE is set.
I propose the following mechanism:
1. Add a "stable" tag to all of our shared repositories. We already do code freezes where we only put in changes to fix bugs that are uncovered immediately after a code push. When the code freeze is lifted, move the "stable" tag to the most recent milestone and leave it there until after the next push/freeze cycle. For example, the most recent cycle would have moved the stable tag from 0.21.2 to 1.0.1 once it became clear there would be no 1.0.2 needed.
2. Add a new site config parameter (something like DW_STABLE) that indicates whether a site is only accepting our "stable" changes.
3. Change the behavior of -update in bin/vcv to only update as far as the "stable" tag if DW_STABLE is set.
no subject
Quick question though: when moving the stable tag on next code push, will we have to do "hg tag -f stable"? Or is there a better way to mark a tag as temporary / move the tag?
no subject
It looks like you will have to use the -f option to move an existing tag to a new revision. That's probably just a safeguard against accidentally trying to use the same tag name twice - I don't see anything wrong with doing it that way. The only other way to move it that I can see is to --remove the tag and then add it back, which is effectively the same thing.