stable releases

[kareila]

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.

Comments

[mark]

I like this.

(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...)

[cesy]

AO3 recently moved from Subversion to Github, if you want to hear about how it went for us for retraining the community and so on.

[mark]

I'd be very interested in hearing how it went!

[cesy]

elz was both co-chair and senior developer at the time, so is probably best placed to summarise what we learnt. pixel, enigel and mumblemutter were also heavily involved.

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.

[necaris]

Google Code? They support hosting with Mercurial IIRC...

[pauamma]

Alternative: offer a "download tarball" way of getting the sources. Then it just becomes a matter of updating dreamwidth.latest-stable.tar.gz (or whatever) file.

[kareila]

Even if we did that, the other sites would still need to run the update script to refresh the linked repositories we don't control. I think it makes more sense to bake it into the existing update script. It's also less effort for us to maintain if all we have to remember is to update a Mercurial tag.

[pauamma]

But the other sites would have to treat updating dw-free and updating TheSwhwartz/etc. differently anyway, unless the "stable" tag is valid across all external repos, which I would rather not rely on. Or am I missing something?

[kareila]

No, my idea was for the update script to treat our repos differently, not to split up the process to the end user.

[fu]

You can setup a downloadable tarball of any revision in mercurial, but it needs to be enabled in the config. (That is to say, by adopting the "stable" tag, we'd also have an automatically generated reference to a tarball to the latest stable revision)

[pauamma]

Thanks

[fu]

I will tag the latest tag in this code push with stable just before I go.

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?

[kareila]

Thanks for coming back and commenting on this - it reminds me I need to open the bug for the related code changes.

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.

[afuna]

Hm, another thought and I'm not too sure about this considering that the last time we played with branches we ended up with people being unable to update to the right one, but:

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...

[kareila]

Yeah, we tried that before and abandoned it. Mercurial just doesn't seem to work as well with branches as other version control systems, and I don't think we need the added complexity.

[kareila]

This is now Bug 3755.