Page MenuHomePhabricator

Adopt Semantic Versioning format for WMF deploy branches beginning with 1.27.0-wmf.1
Closed, ResolvedPublic

Description

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.

Related Objects

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 22 2014, 3:10 AM
bzimport added a project: Deployments.
bzimport set Reference to bz65306.
bzimport added a subscriber: Unknown Object (MLST).
greg created this task.May 14 2014, 8:13 PM

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.

greg moved this task from To Triage to Backlog (Tech) on the Deployments board.Dec 1 2014, 11:49 PM
hashar updated the task description. (Show Details)Dec 2 2014, 11:06 AM
hashar set Security to None.

It seems that task is a complete duplicate of T67289, probably to have it under the Deployment-systems Bugzilla component.

Can we merge it as a duplicate of T67289 and add to it the Deployment-systems project?

greg closed this task as Invalid.Dec 2 2014, 6:28 PM
greg claimed this task.

Or we can just close this one, and file blocking bugs against T67289 that describe the changes needed in eg make-release.

{{DONE}}

greg moved this task from Backlog (Tech) to Done on the Deployments board.Jan 8 2015, 5:36 PM
Legoktm reopened this task as Open.May 14 2015, 9:22 PM
Legoktm added a subscriber: Legoktm.

Re-opening, they're not duplicates.

[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
hashar removed a subscriber: hashar.May 14 2015, 9:33 PM

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.

Legoktm renamed this task from Adopt Semantic Versioning for WMF deploy branches (eg 1.23.0-wmf.6) to Adopt Semantic Versioning format for WMF deploy branches (eg 1.23.0-wmf.6).May 14 2015, 9:39 PM

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.

Agreed. Clarified bug summary that we just want to adopt the *format*, not necessarily the entire semver process.

Legoktm removed greg as the assignee of this task.May 14 2015, 9:40 PM
mmodell moved this task from Done to In-progress on the Deployments board.Jul 13 2015, 6:44 PM

@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.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 23 2015, 7:40 AM

@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?

Maybe we should try using a semantic version for next week's branch and see if anything breaks?

Sounds like a good idea to me :) Will this require any changes to make-wmf-branch?

Sounds like a good idea to me :) Will this require any changes to make-wmf-branch?

Maybe the command line argument validation but I don't really think it will be much, if anything.

mmodell claimed this task.Jul 23 2015, 8:27 PM
mmodell raised the priority of this task from Lowest to High.
hashar added a subscriber: hashar.Jul 28 2015, 4:58 PM

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/.*)

@hashar: I won't be removing the wmf/ prefix

Change 228039 had a related patch set uploaded (by 20after4):
Update mediawiki version regex to support semantic version

https://gerrit.wikimedia.org/r/228039

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.

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.

Ideally, yes.

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.

That sounds like a tag not a branch anymore.

hashar added a comment.Sep 3 2015, 1:04 PM

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.

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. ?

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.

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?

@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.

mmodell renamed this task from Adopt Semantic Versioning format for WMF deploy branches (eg 1.23.0-wmf.6) to Adopt Semantic Versioning format for WMF deploy branches beginning with 1.27.0-wmf.1.Sep 17 2015, 8:21 AM
mmodell updated the task description. (Show Details)
greg added a comment.Sep 18 2015, 10:05 PM

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?

Change 239562 had a related patch set uploaded (by Florianschmidtwelzow):
Use Semantic versioning format for deploy notes

https://gerrit.wikimedia.org/r/239562

Change 239752 had a related patch set uploaded (by Florianschmidtwelzow):
Adjust SpecialVersionVersionUrl hook handler for upcoming Semantic versioning in wmf branches

https://gerrit.wikimedia.org/r/239752

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?

Yes. Or "1.27.0-alpha.1" to make things easier for the composer semver module, but eh…

Change 239562 merged by jenkins-bot:
Use Semantic versioning format for deploy notes

https://gerrit.wikimedia.org/r/239562

Change 239752 merged by jenkins-bot:
Adjust SpecialVersionVersionUrl hook handler for upcoming Semantic versioning in wmf branches

https://gerrit.wikimedia.org/r/239752

greg added a comment.Sep 25 2015, 4:39 PM

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?

greg added a comment.Sep 25 2015, 4:45 PM

Can we do [[MediaWiki 1.27/wmf.1]] please, for the wiki page names?

I updated https://www.mediawiki.org/wiki/MediaWiki_1.27/Roadmap and https://wikitech.wikimedia.org/wiki/Deployments to reflect that.

Change 241078 had a related patch set uploaded (by Florianschmidtwelzow):
Use new page name for wmf release notes

https://gerrit.wikimedia.org/r/241078

Change 241079 had a related patch set uploaded (by Florianschmidtwelzow):
Use new page name for wmf release notes

https://gerrit.wikimedia.org/r/241079

Change 241078 merged by Greg Grossmeier:
Use new page name for wmf release notes

https://gerrit.wikimedia.org/r/241078

Change 228039 merged by jenkins-bot:
Update mediawiki version regex to support semantic version

https://gerrit.wikimedia.org/r/228039

mmodell closed this task as Resolved.Sep 29 2015, 7:33 PM
mmodell awarded a token.
jayvdb added a subscriber: jayvdb.Oct 3 2015, 10:26 AM

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.

Krenair added a subscriber: Krenair.Oct 3 2015, 1:01 PM

I don't think we should really be supporting the use of wmf branches outside of WMF wikis.

Reedy added a subscriber: Reedy.Oct 3 2015, 1:22 PM

I don't think we should really be supporting the use of wmf branches outside of WMF wikis.

We generally don't. And generally also recommend that people don't use them. But people still do...

hashar added a comment.Oct 5 2015, 7:48 AM

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.

Change 241079 merged by jenkins-bot:
Use new page name for wmf release notes

https://gerrit.wikimedia.org/r/241079