22

I would be interested to get the SO community's opinions on the best application versioning strategy.

My questions:

  1. How do you keep track of your application's version number? Do you have a formal definition of what each number/character in that version represents?

  2. What do the different numbers/strings in the application's version mean for your app?

  3. Do you use any automated updating system in your apps (e.g. something like Sparkle) and how good has it been behaving for you?

  4. Do you have a separate update procedure for beta-testers or pre-release testers of your app?

Improve this question
0

5 Answers 5

Reset to default
16

  • How do you keep track of your application's version number? Do you have a formal definition of what each number/character in that version represents?

  • What do the different numbers/strings in the application's version mean for your app?

I use following:

AppName_<Major>.<Minor>.<Patch/Upgrade>.<BuildNo>

Major - Major version is a definite release of the product. It increased when there are significant changes in functionality.

Minor - Minor version is incremented when only new features or major bug fixes have been added.

Upgrade/Patch - Upgrade refers to the replacement of a product with a newer version of product.It is incremented only when upgrade is provided on designated major release.Patch version starts with 0 and incremented only when bug has been resolved.

Build No - Build Number is incremented when new build is created.

  • Do you use any automated updating system in your apps (e.g. something like Sparkle) and how good has it been behaving for you?

We use building tool which automatically builds app at night which we call nightly build and this increases build number every time a build is created.

  • Do you have a separate update procedure for beta-testers or pre-release testers of your app?

No. Tester tests over nightly build at every morning which we call BAT(Build Acceptance Test) and verify nightly build.

Improve this answer
2
  • Thanks Harry. How easy is it to keep track of that build number? How user friendly is it (e.g. when receiving feedback about a certain version)?
    – Alex
    May 18, 2011 at 13:29
  • @Andrei: Build number is auto generated every time a new build is created using build tool. It is not that much confusing to read app name with version [AppName_1.0.0.159] so no problem with user friendliness in reading app name.
    – Harry Joy
    May 18, 2011 at 13:32
12

Let me note first there seem to be no agreement on the "best" strategy. I can only share my experience on a current project.

  1. The system version is defined manually in a build property. It happens when the team agrees on a new release. As additional versioning we use the build number which is automatically generated by the CI build

  2. We loosely follow the Ubuntu naming scheme YY.MM.version.patch_buildNumber as we have found that Major.Minor versioning messes up customer expectations ;)

  3. There are no automatic updates as the application has to be rolled out by adminstrators

  4. The test releases are more frequent than GA releases, but that should be all.

Improve this answer
3
  • Thanks kostja. Can you expand a bit on messing up customer expectations?
    – Alex
    May 18, 2011 at 13:32
  • 6
    @Andrei In our experience, a change in the major version leads some customers to assume groundbreaking changes in almost every aspect of the application. Furthermore, it forces the developers to think in terms of major releases, unnecessarily holding back a release "are we really ready to roll 2.0?". With the ubuntu versioning it goes more like "does it roll? we ship!"
    – kostja
    May 18, 2011 at 13:37
  • I use something similar to Ubuntu's with a slight variation: YYMM.major.minor.build
    – Don
    May 18, 2011 at 17:19
12

I use Semantic Versioning for my open source libraries and find it much easier to work with other libraries which do as well. It provides a common basis for understanding what a version change might mean. Is the library still in beta? Is a release just for bug fixes? Will there be breaking API changes?

It's basically a codification of the best versioning practices already used by most open source projects.

Improve this answer
10

I tested many version systems and now I'm pretty happy with this one:

[major].[minor].[revision]

  • Major is set manually and refer to a version including major improvements
  • Minor is also set manually and refer to an upgrade/maintenance release, including minor improvements & fixes
  • Revision is generated automatically and refer to an exact revision in the repository.

The last one allows us to be very flexible with versionning. We can ship multiple versions for multiple clients and still be able to debug & fix with ease by getting the specific version from the repos, then merge back with the trunk.

The build, packaging & publishing is fully automated. The only manual action is when we move the last package to the production server by FTP. We want to keep the control on that to ensure we don't deliver crap in production. It goes to a preliminary stage where early adopters can read the release notes and then decide to download and use the version. Customers that face specific bugs can get a fixed version very fast by using one of these versions.

Improve this answer
1
0

I think the key is to make sure a release has some unique number, so that you can easily identify it. How that number is broken down doesn't really matter. The version we use that I care about is major.minor.customerID.buildnumber. The buildnumber is autogenerated from our build script.

Improve this answer

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