All extension branches were removed during the migration to Git. Very few extensions have branches for MW core major version support. There's no longer a simple way to branch all extensions when a core release is updated, and nobody has volunteered to write a script.
So we're back to the situation we had in MW 1.9 and earlier, where it's usually not possible to run any actively maintained extension against an MW core that's not the current trunk.
Given this, I think code reviewers should insist on backwards compatibility with MW 1.20 for commits to the master branch of extensions that are commonly used outside Wikimedia, at least until the release management issue is solved.
-- Tim Starling
It's easy to make a script which creates such branch for each extension, but I'm not convinced that's the right thing to do.
Also, did we make Extension:Distributor properly support branches on git extensions?
In an ideal world we would have perfect tests for all extensions, and jenkins could automatically detect when a change makes it incompatible with an old (but supported) MediaWiki.
Maybe a theme for a hackaton / Google programs / new volunteers.
On 09/11/12 09:43, Platonides wrote:
It's easy to make a script which creates such branch for each extension, but I'm not convinced that's the right thing to do.
Also, did we make Extension:Distributor properly support branches on git extensions?
No.
https://bugzilla.wikimedia.org/show_bug.cgi?id=37946
In an ideal world we would have perfect tests for all extensions, and jenkins could automatically detect when a change makes it incompatible with an old (but supported) MediaWiki.
Yeah, right.
-- Tim Starling
On Thu, 08 Nov 2012 14:08:53 -0800, Tim Starling tstarling@wikimedia.org wrote:
All extension branches were removed during the migration to Git. Very few extensions have branches for MW core major version support. There's no longer a simple way to branch all extensions when a core release is updated, and nobody has volunteered to write a script.
So we're back to the situation we had in MW 1.9 and earlier, where it's usually not possible to run any actively maintained extension against an MW core that's not the current trunk.
Given this, I think code reviewers should insist on backwards compatibility with MW 1.20 for commits to the master branch of extensions that are commonly used outside Wikimedia, at least until the release management issue is solved.
-- Tim Starling
I've always been in favor of the trunk/master of an extension retaining compatibility with the latest stable version of MediaWiki until our next release. (with brand new extensions designed around new features in alpha an exception)
However our LTS support for 1.19 is going to make this more of an issue.
9 Ноябрь 2012 г. 2:52:54 пользователь Daniel Friesen (daniel@nadir-seen-fire.com) написал:
On Thu, 08 Nov 2012 14:08:53 -0800, Tim Starling tstarling@wikimedia.org wrote:
All extension branches were removed during the migration to Git. Very few extensions have branches for MW core major version support. There's no longer a simple way to branch all extensions when a core release is updated, and nobody has volunteered to write a script.
So we're back to the situation we had in MW 1.9 and earlier, where it's usually not possible to run any actively maintained extension against an MW core that's not the current trunk.
Given this, I think code reviewers should insist on backwards compatibility with MW 1.20 for commits to the master branch of extensions that are commonly used outside Wikimedia, at least until the release management issue is solved.
-- Tim Starling
I've always been in favor of the trunk/master of an extension retaining compatibility with the latest stable version of MediaWiki until our next release. (with brand new extensions designed around new features in alpha an exception)
However our LTS support for 1.19 is going to make this more of an issue.
I made quite enough of MediaWiki freelancer work for small to medium MediaWiki installations here in Russia. Most of owners want new extensions or new functionality in old extensions and rarely want to upgrade the core. They consider that "core update is too expensive". It was especially true for 1.17, which introduced a lot of client-side changes. Maybe someday the most of activity (like Wikidata, Parsoid and so on) will be outside of core? Such way core might become smaller part of total project and change less often. Dmitriy
On Thu, Nov 8, 2012 at 5:08 PM, Tim Starling tstarling@wikimedia.org wrote:
All extension branches were removed during the migration to Git. Very few extensions have branches for MW core major version support. There's no longer a simple way to branch all extensions when a core release is updated, and nobody has volunteered to write a script.
Such a script is now done:
https://gerrit.wikimedia.org/r/#/c/32470/
-Chad
On Thu, 2012-11-08 at 17:54 -0500, Chad wrote:
On Thu, Nov 8, 2012 at 5:08 PM, Tim Starling tstarling@wikimedia.org wrote:
All extension branches were removed during the migration to Git. Very few extensions have branches for MW core major version support. There's no longer a simple way to branch all extensions when a core release is updated, and nobody has volunteered to write a script.
Such a script is now done: https://gerrit.wikimedia.org/r/#/c/32470/
As long as this is not solved by enforcing the existence of REL1_20 branches for every extension, are peple expected to try git master for the time being?
https://bugzilla.wikimedia.org/show_bug.cgi?id=16424#c3 lists a few MediaWiki Support Desk postings by people asking how to download extensions for 1.20. I assume people might stick with 1.19 if there's no clear message here.
andre
Tim Starling tstarling@wikimedia.org wrote:
All extension branches were removed during the migration to Git. Very few extensions have branches for MW core major version support. There's no longer a simple way to branch all extensions when a core release is updated, and nobody has volunteered to write a script.
So we're back to the situation we had in MW 1.9 and earlier, where it's usually not possible to run any actively maintained extension against an MW core that's not the current trunk.
Given this, I think code reviewers should insist on backwards compatibility with MW 1.20 for commits to the master branch of extensions that are commonly used outside Wikimedia, at least until the release management issue is solved.
ACK. Also, I do not think that branching in accord with core is the right thing to do for extensions as then a user is faced with a squared number of potential combinations.
Extensions instead should have proper versioning (of their own), with clearly stated support for/requirement of a Me- diaWiki release/HEAD, so no extension releases are made just to increase the version number even when no code was changed, and on the other hand breaking changes in exten- sions can be handled in different extension releases, i. e., you don't have to update to LiquidThread 3.0 just to get compatibility with MediaWiki 1.21.
Tim
On Nov 8, 2012, at 11:08 PM, Tim Starling tstarling@wikimedia.org wrote:
All extension branches were removed during the migration to Git. Very few extensions have branches for MW core major version support. There's no longer a simple way to branch all extensions when a core release is updated, and nobody has volunteered to write a script.
Such as script is easy to write, and Chad wrote one just now.
But, why would we want to do the auto-branching again? This was a natural side-effect of our directory structure and use of Subversion. Now that we have a choice, I don't think we should be auto-branching all extension on a MediaWiki core release.
Extension maintainers should be able to decide when and where to branch. So that they don't have to backport changes just because someone at the foundation decided to branch all extensions.
Given that ExtensionDistributor will support Git branches soon[1] (by listing the branch names of that extensions' git repo in the drop down menu), I think everything is done.
Given this, I think code reviewers should insist on backwards compatibility with MW 1.20 for commits to the master branch of extensions that are commonly used outside Wikimedia, at least until the release management issue is solved.
That makes perfect sense. The master branch should always be compatible with releases between it and the latest branch made. So when an extension has a REL1_19 and REL1_20 branch, and MediaWiki core is on 1.22-alpha, then git master branch should support 1.21 and 1.22-alpha (if and until the extension maintainer decides that compatibility needs to be broken and makes a REL1_21 branch).
-- Krinkle
Hey,
Extension maintainers should be able to decide when and where to
branch. So that they don't have to backport changes just because someone at the foundation decided to branch all extensions.
+1. Having a script run that makes pretty arbitrary tags in between actual releases for extensions that have real releases and associated tags/branches does not seem helpful at all to me.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
On 19.11.2012 17:08, Jeroen De Dauw wrote:
+1. Having a script run that makes pretty arbitrary tags in between actual releases for extensions that have real releases and associated tags/branches does not seem helpful at all to me.
It is, however, extremely helpful for those extensions that don't have their own release system.
Maybe the script can just skip any extension that has a VERSION or RELEASE-NOTES file.
-- daniel
On Nov 19, 2012, at 5:12 PM, Daniel Kinzler daniel@brightbyte.de wrote:
On 19.11.2012 17:08, Jeroen De Dauw wrote:
+1. Having a script run that makes pretty arbitrary tags in between actual releases for extensions that have real releases and associated tags/branches does not seem helpful at all to me.
It is, however, extremely helpful for those extensions that don't have their own release system.
Maybe the script can just skip any extension that has a VERSION or RELEASE-NOTES file.
Or we don't run it and just create REL branches when we have to and so will others.
Extensions that aren't maintained, aren't maintained.
As a start, I created a REL1_20 branch for extensions that were bundled with 1.20.0.
-- Krinkle
wikitech-l@lists.wikimedia.org