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
(Of course, it makes me think again that we should move to GitHub to make the whole thing way easier... except of course for learning Git when everybody knows Mercurial...)
no subject
no subject
no subject
We had about a month in which we were focused mainly on the transition, during which not much new development happened, and we couldn't really welcome new people properly. Our existing junior and medium level developers particularly hated having to relearn stuff they'd only just got the hang of, but most (not all) people would agree that git is better now we're used to it. We produced a document for existing developers to explain which commands were pretty much equivalent and which were conceptually different, and other places on the web have similar docs. We had to talk people through how to convert patches/branches that they were in the middle of developing, which was more complex for bigger projects. It's possible to import your whole history and give developers proper credit, but only if you can link their old usernames to their Github account, so developers who'd since left and didn't have Github when we imported don't show their credit neatly. We also had to reinvent our commit/deploy process, but the DW model is already slightly closer to the Github assumptions so that should be less of a pain here - AO3 previously gave all coders commit access. We have a separate training project, which is just a simple blog, barely one step up from hello world, but worked well for people to try it out and get the hang of submitting patches using the new process before we moved the real codebase over.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
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.
no subject
How about a stable branch and an unstable branch? I know that's how some projects (e.g., mercurial itself) work. Among other things, we'd be able to get rid of that code freeze post merge...
no subject
no subject