See T67289: Use semantic versioning scheme for WMF (all) releases for reasoning on using this everywhere. This is the sub bug/dependent task for modifying our deployment tooling to support this.
Description
Description
Details
Details
- Reference
- bz65306
Customize query in gerrit
Event Timeline
Comment Actions
Relative python awesomeness: there is a python module that support the semantic versioning spec.
Pypi: https://pypi.python.org/pypi/semantic_version/
Doc: http://pythonhosted.org/semantic_version/
I would myself drop the MediaWiki version entirely in favor of year/week number or something along those lines. Ie 2014-w26, shorter and easier to understand. But that is another debate.
Comment Actions
Or we can just close this one, and file blocking bugs against T67289 that describe the changes needed in eg make-release.
{{DONE}}
Comment Actions
[14:19:09] <legoktm> twentyafterfour: how hard/disruptive do you think implementing https://phabricator.wikimedia.org/T67306 would be? using semver for WMF branches so they would look like 1.26.0-wmf6? [14:20:23] <twentyafterfour> legoktm: so essentially just adding a dash in the version? [14:20:35] <legoktm> twentyafterfour: and the .0 yeah [14:20:59] <twentyafterfour> should not be too difficult, I don't know what hidden assumptions might be lurking in the multiversion code though [14:21:49] <twentyafterfour> I know there is some code that currently validates the format of the version string, so that would have to be adjusted
Comment Actions
I have no problem with following the format of semantic versioning, however, our weekly branch cuts don't necessarily follow the rules of semantic versioning changes. Really they are close to the concept of patch-level releases but the version increment doesn't really tell anything about the content of that week's branch - the changes that are included don't have any way of affecting the version number, it's simply incremented each week regardless of what is included.
Comment Actions
Agreed. Clarified bug summary that we just want to adopt the *format*, not necessarily the entire semver process.
Comment Actions
@mmodell how hard do you think this will be to implement? I'm trying to figure out whether it's worth adding support to T99084: Allow extensions to specify which MW core versions they support in extension.json for non-semver "1.26wmf14"-type version strings.
Comment Actions
@Legoktm: The only tooling related issue I can think of is the "php-" prefix is assumed in several places. Everything after the php- is pretty much arbitrary.
Maybe we should try using a semantic version for next week's branch and see if anything breaks?
Comment Actions
Maybe the command line argument validation but I don't really think it will be much, if anything.
Comment Actions
CI expects them to be prefixed with wmf/. That is to filter them out in Zuul ex:
zuul/layout.yaml: branch: ^(?!wmf/.*)$ zuul/layout.yaml: branch: ^(?!refs/tags/wmf/.*)
Comment Actions
Change 228039 had a related patch set uploaded (by 20after4):
Update mediawiki version regex to support semantic version
Comment Actions
Does this mean that release branches will also be versioned? Right now we have REL1_25 not REL1_25_2 etc. which is a complication.
Comment Actions
Why would we want a branch per patch version (REL1_25_1, REL1_25_2)? The patch versions are cut out of the minor branch which is linear. I. e. we do not have a need to cut a branch per version since patch are a snapshot of minor. I am not sure why we would want to maintain different patch versions for a given minor version.
With the linear branch for a minor version we currently have:
* b85938c (HEAD -> master) New feature # Tip of development * 9c6b03e Development ongoing | * 5e92985 (REL1_25) 1.25 security fix # Tip of 1.25 minor version | * 65fc810 (1.25.2) 1.25.2 patch version # Tag of patch version 1.25.2 | * 637da31 Backport to 1.25 | * 684708b Fix regression in 1.25 | * 11e8dad (1.25.1) 1.25.1 patch version # Tag of patch version 1.25.1 | * 6dd445f New 1.25 minor version |/ * f1086b6 Initial version # 1.25 minor version branch point
Where has with branches per patch version (ex: REL1_25_2) we would get:
* b85938c (HEAD -> master) New feature # Tip of development * 9c6b03e Development ongoing | * 5e92985 (REL1_25) 1.25 security fix # Tip of 1.25 minor version | | * 65fc810 (1.25.2, REL1_25_2) 1.25.2 patch version # ?? | |/ | * 637da31 Backport to 1.25 | * 684708b Fix regression in 1.25 | | * 11e8dad (1.25.1, REL1_25_1) 1.25.1 patch version # ?? | |/ | * 6dd445f New 1.25 minor version |/ * f1086b6 Initial version # 1.25 minor version branch point
Which hardly of any use but I might be missing a point.
#Jdforrester-WMF can you elaborate on Right now we have REL1_25 not REL1_25_2 etc. which is a complication. ?
Comment Actions
Mapping "1.26.0-wmf.7" to "1260" but "REL1_26" to "126?" means adding yet more assumptions into the bot's code about where patches will land.
Comment Actions
How about we also use a semver parsable name for release branches. Then use a semver library to parse the string. So to get the major release you only use the first two version parts. Would that help?
Comment Actions
@JanZerebecki: That is essentially the point of this task.
@hashar: I don't think we need a new branch per patch release, a tag would suffice. But following semantic versioning for both branches and tags, as apposed to the current REL1_25 convention, would be a big improvement, IMO.
Comment Actions
Just to be clear:
I'm making the deployment calendar for the week of Sept 28th (ie, when we branch 1.27).
It should name it "1.27.0-wmf.1" on that page (and https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap ), yes?
Comment Actions
Change 239562 had a related patch set uploaded (by Florianschmidtwelzow):
Use Semantic versioning format for deploy notes
Comment Actions
Change 239752 had a related patch set uploaded (by Florianschmidtwelzow):
Adjust SpecialVersionVersionUrl hook handler for upcoming Semantic versioning in wmf branches
Comment Actions
Yes. Or "1.27.0-alpha.1" to make things easier for the composer semver module, but eh…
Comment Actions
Change 239752 merged by jenkins-bot:
Adjust SpecialVersionVersionUrl hook handler for upcoming Semantic versioning in wmf branches
Comment Actions
My comment on the linked patch:
Sorry, I'm just now replying to this.
Can we do [[MediaWiki 1.27/wmf.1]] please, for the wiki page names?
Comment Actions
I updated https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap and https://wikitech.wikimedia.org/wiki/Deployments to reflect that.
Comment Actions
Change 241078 had a related patch set uploaded (by Florianschmidtwelzow):
Use new page name for wmf release notes
Comment Actions
Change 241079 had a related patch set uploaded (by Florianschmidtwelzow):
Use new page name for wmf release notes
Comment Actions
Change 228039 merged by jenkins-bot:
Update mediawiki version regex to support semantic version
Comment Actions
Announced for API users https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2015-September/000097.html as this broke Pywikibot :/
Comment Actions
Causes T114365: upgrade mwclient (morebots no more log because of MediaWiki semantic versionning) (can no more !log).
Comment Actions
This should be included in tech notices for at least developers & sys-admins, etc?? wmf branches are commonly used outside of WMF, and a version string change is one of the most significant API changes possible as it breaks API version detection.
Comment Actions
I don't think we should really be supporting the use of wmf branches outside of WMF wikis.
Comment Actions
We generally don't. And generally also recommend that people don't use them. But people still do...
Comment Actions
We still have people consuming the WMF wiki API and we had a few scripts breaking due to the version scheme change. Maybe spam announce / api mailing list ? Though I guess by now everyone solved it.