Page MenuHomePhabricator

Use semantic versioning scheme for WMF (all) releases
Closed, ResolvedPublic

Description

MediaWiki releases already support a very sane version scheme following a standard <major>.<minor>.<patch>. I would like to propose that something like the documented semantic versioning scheme be adopted for the other versions as well.

http://semver.org

I've already discussed with Mark Hershberger (hexmode) regarding release candidates and he is planning on doing this. So, "1.23.0rc1" becomes "1.23.0-rc.1". It would be great if WMF releases could follow a similar structure. So, "1.24.0wmf5" becomes "1.24.0-wmf.5".

Why care? Mainly by doing this we can more easily understand what the version is. Also, following a standard allows easier programmatic work. For example, there is a semantic version python package that will parse these easily and cleanly.

https://pypi.python.org/pypi/semantic_version/2.3.0

I’m adopting this module for reading versions on WikiApiary for everything (Mediawiki and extensions). Making the metadata of the release easier to understand will make it easier to write queries like "How many 1.23 releases are running a release candidate?"

Can this be done with no change to current versioning? Yes. But I think it would be nice to set a standard around semantic versions that others could follow.

Note that the Semantic Versioning convention allows a build field as well prefixed with +. The Siteinfo/General API method already reveals the Git version number, but the truncated hash could be used there if desired. I note that there are at times multiple git commits associated with one WMF version number. (e.g., https://wikiapiary.com/w/index.php?title=MediaWiki.org/General&diff=next&oldid=902490)

Related:


Version: unspecified
Severity: enhancement

Details

Reference
bz65289

Related Objects

StatusSubtypeAssignedTask
DeclinedNone
OpenNone
Resolved demon
Declined mmodell
ResolvedLegoktm
Resolved GWicke
Resolved mmodell
Resolved GWicke
Declined GWicke
Resolvedthcipriani
DeclinedNone
Resolved mobrovac
Resolvedakosiaris
Resolvedakosiaris
Declined mmodell
InvalidNone
Resolved mmodell
ResolvedJdforrester-WMF
Declined mmodell
Resolved mmodell
Resolved mmodell
Resolved mmodell
Resolveddduvall
ResolvedKrinkle
ResolvedKrinkle
Resolved mmodell
DuplicateKrinkle
ResolvedKrinkle
ResolvedKrinkle
ResolvedPRODUCTION ERRORMaxSem
ResolvedKrinkle
ResolvedKrinkle
ResolvedKrinkle
ResolvedKrinkle
ResolvedKrinkle
Resolved mmodell
ResolvedNone
ResolvedJoe
ResolvedNone
ResolvedJoe

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:08 AM
bzimport set Reference to bz65289.
bzimport added a subscriber: Unknown Object (MLST).

I believe this bug has already been resolved in part. When looking at the tags for core [1] we already have a 1.23.0-rc.1 which is nice. At this point I am not sure about the alpha tagging for WMF tough.

[1] https://git.wikimedia.org/tags/mediawiki%2Fcore.git

Wondering whether to move this to "Wikimedia > Deployment Systems" first...

Greg?

This would be surprisingly disruptive in our deployment tooling.

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/

That being said, I would prefer a RFC to be filled about usage of Semantic Versioning and have it advertised on wikitech-l / mediawiki-l lists. Not to bikeshed, but to make sure the community is aware of the changes and have an opportunity to cast its voice.

I remember that dropping the "1." prefix from the version number was discussed some years ago on wikitech, and that at least that that point people where generally against it.

For Wikidata, we have switched all our components over to follow semver.

(In reply to Antoine "hashar" Musso from comment #4)

That being said, I would prefer a RFC to be filled about usage of Semantic
Versioning and have it advertised on wikitech-l / mediawiki-l lists. Not to
bikeshed, but to make sure the community is aware of the changes and have an
opportunity to cast its voice.

As far as I can tell, this would only affect RC releases. That seems like it is ripe for bikeshedding.

(In reply to Mark A. Hershberger from comment #6)

As far as I can tell, this would only affect RC releases. That seems like
it is ripe for bikeshedding.

Note that I was only talking about tarball releases, not WMF's versioning.

Note that I was only talking about tarball releases, not WMF's versioning.

They're tightly coupled, however, so one changes with the other.

Is the goal of this ticket to adopt the semver practice, or just the format?

Legoktm writes:

Is the goal of this ticket to adopt the semver practice, or just the format?

AFAICR, just the format. The practice wouldn't hurt, but the format is
what matters for software (like WikiApiary) that uses the format.

As we are rethinking and retooling our deployment process, I think we should standardize around semantic versioning for release branches & deployment tags. At least the format, and to the extent possible we should also practice good versioning.

The chosen suffixed lead to the wrong version comparison. 1.26.0-wmf.7 would be a newer version than 1.26.0-rc1. But in reality it would be the other way around. A way to make that fit would be either start rc with 1.26.1-rc1 or choose suffixes starting with letters that sort in the expected way.

Legoktm claimed this task.

This was implemented a while back.