What is the reason to use release version as a release title on GitHub?

It looks like this enter image description here And it looks like a common practise. Almost all popular repositories use it.

What is the use case to duplicate release tag to the release title?


Examples: Facebook React, Atom, Kubernetes, CryEngine

  • Show us the actual posting where you saw this. This little screenshot doesn't tell us anything; we don't even know what the repository is. Mar 27 '17 at 15:12
  • @RobertHarvey added 5 examples. But the question is not about some repositories. It's about usage of "release titile" on GitHub in general.
    – user980828
    Mar 27 '17 at 15:21
  • 5
    What else would you use? Random dictionary words? Emoticons? Or are you complaining that they don't add the project name as a prefix? Mar 27 '17 at 15:21
  • Are you expecting projects to give unique names to releases? That seems...unnecessary.
    – Thomas Owens
    Mar 27 '17 at 15:23
  • 2
    The "main functionality" will be in the description below, where it belongs, because often there is way more functionality in a release than can be included in a title. It makes perfect sense to me that that title of the release will be the specific version number. It might help to turn your question around and ask why there's a git tag that duplicates the release title. The answer to that is that git tags are useful, but in a different way than a release title.
    – Eric King
    Mar 27 '17 at 15:31

How to manage release with Git and GitHub ?

The Git standard way of identifying a release is to create a version tag. This tag marks a specific version of your software in the change history of your repository. Most teams work with tags, because these are directly available in the repository and can be used in git commands.

The releases are a GitHub feature for packaging software for delivery. This allows to add some downloadable binaries associated to the release. So, in practical terms, the release is some added web content related to a tagged version; it's not something known in you local repository.

To create a release on GitHub, you have to enter a mandatory new tag identifier (that will be created to identify the release) and an optional release name.

Naming conventions

As the tags are the primary identification of a release, it's managed with care. Usually it follows the semantic versioning convention (or some variant).

For the name, there is no universal convention. But if it is left empty, GitHub will simply take over the version tag that you've just created. This is why so many projects reuse the tag id for the release name: it's not a deliberate choice; they don't even have to do a copy-paste; it's just that they had no desire/time/interest in using a more creative description, and let GitHub define it by default !

You can of course use a different convention. You could perfectly use a code name (e.g. "Longhorn SP2" instead of "v6.0.6002" like Microsoft is doing for Windows, or "Ice cream sandwich" instead of "v4.0.4" like Google is doing for Android). But maintaining such a naming standard in the long run requires a lot of creative people if you want to keep the names unique. More realistic is a mixed approach: use the default version tag for minor releases, but identify a codename for important releases (especially if these are significant for marketing)

You could also think of identifying main new features. However this is of very limited use. First, if you're adept of separating corrective releases and functional releases (as proposed by ITSM version release management guidelines), you would have some troubles finding a meaningful name for half of your releases. Then, this scheme works only with small software: if you have an enterprise grade software, the main functions would be far too difficult to summarize in the couple of words that remain visible on the GitHub release page. This kind of information is best put in a release note.


This is a larger screenshot of the actual page you found.

enter image description here

Notice that it says Docker/Toolbox in the upper left hand corner of the page, so you already know what this page is about.

The title of the page is v17.04.0.ce-rc1, because that's the version of Docker/Toolbox that is being released. Savvy readers will recognize that this is a Release Candidate, as evidenced by the "Pre-release" indicator and the rc1 as part of the version number.

In short, if you look at the whole page (instead of just the obtuse title), it does make sense.

I would also note that it was quite easy to find this in Google, just by searching on the release number you gave me.

  • 2
    The question is not about version naming. It's about usage of GitHub functionality. Why do we need release title if it's always equals to release tag?
    – user980828
    Mar 27 '17 at 15:28
  • 3
    No, the answer is "because v17.04.0.ce-rc1 is a more specific and descriptive title." That it also happens to be the same as the version number on the release tag is just a coincidence. Mar 27 '17 at 15:40
  • 4
    Coincidence doesn't necessarily mean raw chance, it means two independent things that happen at the same time. There's a good reason to have the release title be the version number, as explained above. There is also a good, separate reason to have a git tag with the version number for each release. The fact that they both appear on the same page in close enough proximity to give you confusion is coincidence.
    – Eric King
    Mar 27 '17 at 16:33
  • 1
    @user980828 Or perhaps they copy and paste the release title into the tag. Either way, you're way over-thinking this stuff. Tags are not 1-to-1 with releases, and they serve different purposes. It just so happens that it makes sense to have, in this instance, a tag with the same information that exists elsewhere. It's a useful redundancy. It's not the end of the world.
    – Eric King
    Mar 27 '17 at 16:53
  • 2
    I would be fairly irritated if I didn't have the choice. Maybe I want to put "Release Candidate Bluecreek, Version 17.04.0.ce-rc1" as the page title instead. That most people just paste the version number into the title creates a reasonably good informal convention. But it's not a rule or law, or even a guideline. It's simply that Github was polite enough to give us the choice to put something else in the title. Mar 27 '17 at 16:56

Why even have a release title at all?

You can push just a version as a tag, but Github will not show it as the 'latest' release on the github page unless you give it a release title. Many projects suffers from this and have outdated 'latest' versions showing on their github page.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.