Versioning Gitorious

As a service to users with Gitorious installed on their own server(s), we’ll be giving Gitorious a version number. We’re aiming at cutting releases on a semi-regular schedule (like once a month). Hopefully, this will make it easier to know if and how to upgrade your instance. We will provide a changelog that summarizes new features and bug fixes, and use a versioning scheme that says something about the extent of the upgrade.

Versioning scheme

We have not yet decided on the exact form of the versioning scheme, but here’s the general idea (thanks for good suggestions, chrashanddie). The version number will be four digits: Product.Major.Minor.Bugfix. We’ll start at 1.0.0.0. Here’s the intended meaning of each digit:

Bugfix

Obviously, bugfixes. Should be a no-brainer to apply.

Minor

Minor changes should apply cleanly simply by pulling it into an existing Gitorious setup. As such it may not require any configuration changes to preserve existing functionality.

Minor changes may include new features or minor changes/improvements to existing features. In some cases a feature may require changes/additions to configuration in order to apply.

Major

Major changes may or may not apply cleanly without configuration changes. Major changes may also require changes to the database.

A major upgrade may substantially change existing features, introduce new ones that are in some way incompatible with existing functionality, and may even remove existing functionality.

Product

This number will stay at 1 for the foreseeable future. It will change if we ever decide to significantly change the heart and soul of Gitorious.

Release schedule

As soon as the versioning scheme is landed and documented, we will cut the 1.0.0.0 release (or similar). Changes after that will be recorded in a changelog and released according to said scheme. We will keep gitorious.org on rolling deployment, so there may be several gitorious.org deployments per each release. Releases will be cut whenever they make sense, but as I said, we’ll aim at releasing something every month.

Feedback?

We need your feedback on this. Is this a good idea? A bad one? Any input on the versioning scheme? Let us know what you think!

10 Comments

If I were you, I’d drop the initial “onepoint” and just have three digits. You did say it would stay at one anyway (ok, for the foreseeable future) so in reality it contains no extra information.

Also take a look at: http://semver.org/ for further information. I wouldn’t necessarily suggest all of it, but it makes a lot of sense.

Personall, I think four digits is too much, just go with three :) Your most significant digit will be when backwards-incompatible changes or major changes happen, the middle digit is minor increments and the last is bugfixes.

Andrew: Thanks for your feedback! We’ll think about that first digit. I like having the ability to go to 2 if the product at large changes significantly, even if that is unlikely to happen anytime soon. All in all it doesn’t matter much of course, but going from 1.x.y.z to 2.0.0.0 will communicate change at large.

I’m a huge fan of semantic versioning and use if for any kind of OSS library/API I work on. However, I find it hard to adopt in its entirety for an end user application such as Gitorious. The above scheme is intended to be an interpretation of semver for Gitorious.

It looks good, but would probably require some more internal discussions. As a product manager, I know that the only way to get it clear in most people’s minds was to have a number of use cases (more in depth than what is displayed here); however not necessarily public.

Also, my nickname is “crashanddie”, not “chrashanddie” :P

This being said, what about packaging? The packaging is usually closely tied to version numbers. What I mean by this is that having a packaging and distribution “ideology” written down really helps with future decisions.

Things that could help answer to the “how do I upgrade my production gitorious? Do I just git pull and pray I get the right version?”; “Will you have tags available so that we can easily get in a detached state, for example: git checkout v1.1.0.1″; “What branch is bleeding edge?”; “What branch is always stable?”; “How long will you maintain branch 1.1?”.

To be honest, I don’t know the answer to most of those questions. You’re dealing with a development method and distribution that is quite foreign to the way I deal with my products professionally: Gitorious in our case is only used for development purposes — we compile and package our product into binaries before distributing to customers, so we don’t have to worry about them getting the wrong source compiled.

For marketing reasons, dropping the first digit will help better communicate that your software is under heavy development.

Just consider the case of Google Chrome. If they decided to stay micro-numbering the releases like 3.2.1, 3.2.2, 3.3 etc, people would think that from 3.2 to 3.3 it’s not relevant to update…

If having in the near future a gitorious number “22, 23″ not a good option, i suggest that you adopt ubuntu-like version numbers:

10.4 means 2010 april, you can even add a bugfix to the end like:
10.4.1, 10.4.2 etc…

Bigger numbers have a good impact to adoption.

Going back to the browsers… Firefox 4 is just in par of Google Chrome in speed and features, but, at the time Firefox will be released, Chrome probably will be on version 8 or something like, so people would just compare the numbers and think that “Chrome 8″ > “Firefox 4″ (8>4).

This is also a good strategy to get on the market of Internet Explorer. Soon chrome version will be bigger the the “IE9″ and this will indirectly transmit the message that as the version number is bigger, then probably it’s better.

@brodock: I like Ubuntu’s versioning scheme a lot too, it avoids the entire question of marketing in version numbers.

However, I don’t think we’ll be doing 6 month releases like Canonical does, not that it *has* to matter much. But let’s say we make one release in February, one in March and then no releases before August. That would leave us with 11.02, 11.03 and 11.08 – how does that communicate?

@Sebastian Packaging is another issue we will solve this year, but I think we’ll have to do one thing at a time. When “1.0.0” drops it will drop in the form of a tag, so your upgrade process will look like `git fetch gitorious && git merge gitorious/1.0.0` (given that you have a “gitorious” remote). We haven’t decided yet on how to distribute gitorious in the future, but we are working on that too.

As for stable, bleeding edge and so on, we will not change our development routines. master has been and will stay a “stable bleeding edge”. That is, gitorious.org is deployed (indirectly) from master, and it will always contain all stable functionality. New features will typically be developed in feature branches until they’re stable, at which point they’re merged into master.

@Marius It’s not the most beautiful one, but I think that if Gitorious makes it clear how does the version numbering work, it shall not confuse users. Considering that the “month” number will only change when the change is not just a fix, version growth can even be minimized. (Only increase it when there is a new feature or a big change/fix. Small ones that are relevant shall be released as “bugfix versions”.

As you are not pretending to have previsible release cycles, I think that any sequential incremented only version numbers will have bad impact on the image of Gitorious as a product.

Another one that can be used is the first digit being the year and the second one incremental. For example: 2011 the first release will be: 11.0.0 the followed by 11.1.0 and also let’s space for bugfix releases like 11.1.2 etc. By doing this you will still comunicate that the product evolutes and can have the best of both worlds.