If you have been wondering about that for a long time, this is the place to be

Introduction

Really ?! Why did you write a post about this ?

Because we couldn’t get any information about that, mainly due to the fact GitHub source code is still not open (that’s paradoxical for the most important FOSS platform promoting Open-Source, isn’t it ?)…

Okay… But does it matter ?

Actually, it does. It’s always good to know how the data you finally see is fetched and displayed on a page.

So we decided to run some tests on our own, to “reverse engineer” and understand what we faced (what a terrible situation).

If you don’t feel at ease with the Semantic Versioning, I invite you to pursue a very interesting reading here (yeah, I know, your browser is telling you that page is insecure).

The answer !

Rule n° 1 = DATE IS THE KEY

As you surely already know (‘cause it’s the most common case), GitHub will display tag according to their creation date. So the most recent tags will be on the top of the list.

We use as “proof” the CakePHP’s tags page, as below :

This is a good thing for projects with previous versions maintained on other branches : Their users may notice “new old versions” easily.
For “regular” projects, this first case will often match.

Rule n° 2 = DEVELOPERS, DON’T WORK TOO MUCH ()

The rule n° 1 (as each existing rule on this planet) got an exception : tags committed close in time. Explanations :

If you create some tags at the same moment (let’s say in less than an hour, we don’t precisely know how long it requires), they will appear in their semantic order. For instance, the following tags :

1.1.0 > 1.1.0-beta > 1.0.19 > 1.0.3 > 0.9.1

… would be displayed as above, even if (for instance) 1.0.19 has been created after 1.1.0.

You should expect close-in-time tags appearing in this very order, even if their creation dates do not respect the same previous condition !

Demonstration, on the following screen shot, the tag 0.3.1 has been committed after 0.3.2 and 0.3.5, but appears before them !

When you don’t know that, it’s pretty confusing. You push some stuffs, and never got what you expected

Rule n° 3 = DEVELOPERS, DON’T F*CK WITH NAMING

Now you know that, you may start browsing repositories on GitHub ! But before starting your own versioning on a project, please read the following :

Don’t change your tagging format (at least for your close-in-time tags), ‘cause GitHub won’t “know” how to handle them.

For instance, if you create a tag named 2.3.4 and afterwards another named v3.0.0, the second one won’t appear where you expect it to be

---

Piece of advice (if you correctly read the whole post you surely already know what to do in such a case) : Wait some hours before changing your tag format on your repository, or just… don’t