On Sun, 2005-13-03 at 06:55 -0800, Brion Vibber wrote:
Unless you're checking in something that will
never ever be supported in
the future, or is a hack specifically for a problem in the 1.4 branch
that does not exist in the next version, it needs to go in HEAD.
If it doesn't go into HEAD, it will not be there in the next version. It
would be pretty lame if we fix a bunch of bugs in 1.4 and have them come
back in 1.5, wouldn't it? :)
I thought things worked differently.
It's a common version-control practise to make a stable branch before a
release, and do only bug fixes, stabilizing changes, and release-related
mods (version number, release notes, etc.) in that branch. Then, after
the release milestone and hoopla, at your leisure you merge all changes
back into HEAD as one big packet. You can also continue to make bug
fixes in the stable branch and merge each group of changes back to HEAD
after a minor release.
I'm not saying MediaWiki has to do it that way; I'm just saying that
that's a pretty common thing to do.
I generally prefer to see things checked in on HEAD
*first* and *then*
on REL1_4.
I don't think that's a good idea. Not that my opinion on the subject
matters, but here's my thinking: if you're doing stabilizing bug fixes,
you should write and test them for the stable environment, not for a
moving-target development environment.
Also, merging between branches is an inherently destabilizing action;
one should inject that entropy from the stable branch into the unstable
branch, not the other way around. In other words, you should pay the
price in the dev branch, not in the stable branch.
But, hey: you da boss. I'll dev in HEAD then port to RELX_Y in the
future, if I need to. And I'll merge this changeset from HEAD to REL1_4
in a day or two.
~Evan
--
Evan Prodromou
evan(a)bad.dynu.ca