kareila: (Default)
kareila ([personal profile] kareila) wrote in [site community profile] dw_dev2011-05-20 09:22 am

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.
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)

[staff profile] mark 2011-05-20 03:57 pm (UTC)(link)
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: "Cesy" - An old-fashioned quill and ink (Default)

[personal profile] cesy 2011-05-20 04:01 pm (UTC)(link)
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: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)

[staff profile] mark 2011-05-20 04:05 pm (UTC)(link)
I'd be very interested in hearing how it went!
cesy: "Cesy" - An old-fashioned quill and ink (Default)

[personal profile] cesy 2011-05-20 04:46 pm (UTC)(link)
[personal profile] elz was both co-chair and senior developer at the time, so is probably best placed to summarise what we learnt. [personal profile] pixel, [personal profile] enigel and [personal profile] 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: me looking dapper at a wedding (Default)

[personal profile] necaris 2011-05-21 11:21 am (UTC)(link)
Google Code? They support hosting with Mercurial IIRC...
pauamma: Cartooney crab wearing hot pink and acid green facemask holding drink with straw (Default)

[personal profile] pauamma 2011-05-20 04:22 pm (UTC)(link)
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.
pauamma: Cartooney crab wearing hot pink and acid green facemask holding drink with straw (Default)

[personal profile] pauamma 2011-05-20 06:27 pm (UTC)(link)
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?
Edited (Now with 100%less scrambled text) 2011-05-20 18:29 (UTC)
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)

[personal profile] fu 2011-06-19 05:22 pm (UTC)(link)
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: Cartooney crab wearing hot pink and acid green facemask holding drink with straw (Default)

[personal profile] pauamma 2011-06-19 05:59 pm (UTC)(link)
Thanks
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)

[personal profile] fu 2011-06-19 05:19 pm (UTC)(link)
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?
afuna: Cat under a blanket. Text: "Cats are just little people with Fur and Fangs" (Default)

[personal profile] afuna 2011-06-20 12:08 pm (UTC)(link)
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...