Version numbers best practice: how to turn a bugless RC into Final without forcing users to download a distro that has no useful changes?

Question

I'm trying to adopt a good practice of naming versions.

I've finished coding my project. As it may contain unknown bugs, i tag it "v1.0rc1". When all bugs are found and fixed, i'll tag the updated version as "v1.0".

But what if no bugs are found and the release candidate turns out to be good enough for a final release?

With the SCM, it's as simple as tagging the last commit with "v1.0".

The problem is with updating the distro. I use RubyGems. It's convention is to store the version number in code. When building a gem (the distro), RubyGem places the version number into the gem's filename and uploads it into the repository.

If i change the version number and update the gem, all users will be forced to download the whole distro without any benefit. I consider this to be a poor practice.

On the other hand, i neither want to stay with "v1.0rc1" forever nor release a final version that may contain bugs.

Is there an approach that lets you both stage a release candidate and don't force users to redownload a useless release?

Answer 1

Don't sweat on it, because:

1. Some products never "get out of beta" or bother with the rc scheme, so they avoid the problem altogether.

2. Most users would not have downloaded the rc version unless they specifically requested for it, so the majority would not be impacted unless you had to yank the current release and make another release soon after, now that would really inconvenience people. (I could recall more than a handful of gems that did just that, but I digress)

3. There will always be bugs.

Answer 2

The problem here is that code changes don't propagate properly to the consumer of your build. Since the consumer has no way to tell what has changed and what hasn't and what the effects of these changes might be, they have to download everything again.

What you can do is split your product into many small parts so downloads will be small. But this is a huge effort to maintain for something that will save people a couple of seconds at today's download speeds (your product isn't 400MB, is it?).

My hope is that we will eventually be able to create build systems that use hashes and timestamps to determine whether something has changed. This information could be included in the download or the server which offers the download and dependency management systems could

1. download only the changed parts (i.e. the single file which contains the new version number or just the new value for the single constant in said file)
2. and determine if a change in your code could affect my code and if so, which parts.