Last modified: 2014-05-15 13:21:25 UTC
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: * Semantic MediaWiki has adopted this going forward. https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/109 * This was mentioned briefly in bug 61025.
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.
