Use semantic versioning in tags when exporting to Github

[nessthehero]

When the SVN repo is exported to Github, some of the tags do not fall under semantic versioning guidelines, e.g. A.B.C where A is the major revision, B is the minor revision, and C is the patch version.

For example, the latest tag on Github as of the creation of this ticket is "3.8".

This seems a petty request, but package management console applications, such as Bower, seem to ignore Github tags that don't follow this convention, and it is impossible to upgrade via a simple command, such as "bower update". Doing a fresh "bower install Wordpress/Wordpress" will install the latest version of 3.7.x, and will continue to do so until a new tag, such as 3.8.1, is added to the repo. It is a convenience to be able to upgrade my local copy of wordpress and quickly use it in my Grunt based workflow.

It would be great if this could be changed.

Thanks.

[johnbillion]

Surely this is an issue with Bower if it treats 3.7.x as newer than 3.8? Omitting the trailing .0 for a release version number is common practice.

[bpetty]

This is likely because NPM packages are ​required to use semantic versioning themselves. This isn't Bower-specific.

I would also like to see this myself anyway though because when you do mirror core SVN using git-svn yourself ​like I have, and don't use the hack that the official GitHub mirror does to rename branches with -branch appended, you end up with both a branch named 3.8 and a tag also named 3.8 even though they are two very different things. Git still supports this fine, but ends up requiring you to explicitly specify which you want like git checkout refs/tags/3.8. It can be confusing sometimes.

[nacin]

WordPress doesn't actually use semantic versioning. "3.8" is the major version and ".0" is the minor version. Or more accurately, "3.8" is the minor version and ".0" is the patch version. Not that we shouldn't make this change to be compatible with tools following semver, but I want to state the obvious.

[bpetty]

I don't think anyone implied that we switch to semver rules officially. There's nothing wrong with having version numbers that follow formatting rules of semver, even if we have our own custom definitions for them in terms of compatibility.

[markjaquith]

So what if I additionally tagged x.y versions as x.y.0 and pushed those to GitHub? I have no objection to doing that. There would be redundant 3.8 and 3.8.0 tags, but that's not the end of the world.

[nacin]

develop.git now leverages this. It'll be pushed to GH soon.