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