stable releases
May. 20th, 2011 09:22 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
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.