Last modified: 2012-11-13 04:06:11 UTC
Split off from bug 35574, which is fixed (adding basic support for it in ExtensionDistributor). (In reply to bug 35574 comment #6) > Git support exists. Might need some work for extension branches in the future, > but considering we don't have a format for doing this yet, support can't be > added So it is working for "master" right now. The support for using branches in the ExtensionDistributor is bug 37946. This bug is for performing the actual creation of branches. I don't think we need to find a "format". We can stick to using REL1_* branches for the ones we want to expose in ExtensionDistributor, and if an extension maintainer wants to create other branches, then that's perfectly fine. The points to be resolved are these two: * Doing the initial import. Since in SVN branches are copies, dealing with history is a bit complicated. Ideally we'd pick a point for each branch in each extensions's master that becomes that branch's HEAD (rather than importing the branch and thus basically duplicating history? Not sure if this is as bad/complicated as it seems). I've thought about maybe skipping this step, but I don't think that's realistic (yet). We don't want to keep mixing SVN and Git for te same extension (moreover since there are SVN-only and Git-only extensions / which are problematic right now). Users should be able to download old versions from Git. * Keeping it up to date. Do we automatically branch all extensions when we branch core? I don't think that's a good idea. It shouldn't be a problem to make this a task for the extension maintainer(s). In Git it's also easy to create a branch afterwards from a certain revision. If an extension does not have any improvements over a release cycle, there is simply a gap in the number of branches available. Should be fine. Users can pick the newest version compatible with their version of MediaWiki.
cf. bug 37946 comment 3, I'm not sure what discussion there is left. I think it's pretty straight forward and obvious: * We use branch names like REL1_19, REL1_20 * We don't import from SVN (if wanted, we can do that later, not relevant to this bug now) * Maintainers are responsible from their branching, no mass-branching after each release. That way the extension distributor etc. can display the supported versions. And people would naturally select the older version if no newer version is available. This also avoids "fake" releases from showing up in the history. Various extensions already have a REL and/or wmf-branch.
(In reply to comment #1) > * We don't import from SVN (if wanted, we can do that later, not relevant to > this bug now) > It's not very easy to do this since the masters were already done. Since the branches were awful approximations of what might work as of a given branch point, we don't need to waste time exporting stuff from SVN. Just `git branch REL1_nn master@{date of branching}` -- certainly no worse than the branches we were making before.
