What is the standard way of describing how software products are released and the proportionate order of magnitude to which the changes relative to the software product are conveyed?


  1. Release
  2. Update
  3. Patch
  4. Bug Fix


or Is

  1. Update
  2. Patch

too terse?

As an end user I'd think that all bug fixes are patches (insofar as they are not 100% new code) and all patches should be updates (insofar as they don't degrade the product) and all updates should be releases (insofar as they are actually released), but this really doesn't help anyone understand why they need to get them.

Then, if the person who makes the software change appends "critical" or "zero-day" in the notes, I would be unwise to leave the changes unapplied.

  • "Order of magnitude" is in your title but not in the question. Suggest rephrasing. Jan 28, 2011 at 16:22
  • 1
    @Brian, there may be bigger problems than that with my question, especially since "Order of magnitude" is in the first run on sentence - I don't blame you if you didn't see that. Jan 28, 2011 at 16:25
  • "standard"? As in POSIX standard? Or GNU Standard? en.wikipedia.org/wiki/Software_versioning
    – S.Lott
    Jan 28, 2011 at 16:37
  • @S.Lott I'm more interested in what I call it when I e-mail a notification to clients and the testing dept than what the numbers between the dots signify. But if there was a legit standard nomenclature that knowing both answers would be the answer in my book. Jan 28, 2011 at 18:30

4 Answers 4


Where I work we use the following terminology:


Developers share these around with each other (example-0.0.1-SNAPSHOT) and are built over and over while developers get to grips with the various user stories and tasks.

These never go beyond the development servers. To get beyond 0.0.1-SNAPSHOT you normally have to go through a release, but major rework/rethinking can trigger a skip to 0.0.2-SNAPSHOT and so on.


These go out to production (example-0.0.1) and are only built once. They represent a releaseable artifact of some kind. Once the release build is complete, the developers move on to use 0.0.2-SNAPSHOT for further mainstream development.


These are fixes to previous versions of the code that can't be covered by an update to the existing snapshot (example-0.0.1-Patch-1). They represent some kind of important update.

Decoding the version numbering

The numbering is arranged as major.minor.revision which is pretty common.

Major is usually a rewrite and is normally paid for.

Minor is usually a large collection of bugfixes wrapped up into a single manageable update and is free. This is what a customer would see as their monthly update.

Revision is associated with a single development sprint/iteration and represents a small collection of bugfixes.

  • Release - user pays
  • Update, Patch, Bug Fix - user paid for service contract (Could be included with Release)
  • Upgrade - User pays again

I personally enjoy a 4-numbered version, however there's no standard for versioning.

The last digit I auto-increment everytime I deploy, so I'm sure I always have a new version without having to worry too much about the significance. Usually I'll increment the third number only when I add a noticeable feature or behavior of the program (as opposed to fixing a bug or modifying the program on a level which will never be perceivable by the user). Reserve update for relatively important changes, and reserve the release for major changes.

  • What do you call that auto-inc release then - a "Deployment" or a "Build"? Jan 28, 2011 at 16:18
  • I call it a revision :)
    – Neil
    Jan 28, 2011 at 16:22

There's nothing particularly standard about this. Some common uses:

Release: a new version with major changes from the old version. Typically, the user pays for this as a new product, or as an upgrade from a previous release.

Update: a new version that probably has significant changes to functionality, or many minor ones. Typically, this is either free, or the user gets it with a normal service contract.

Patch: a new version that generally doesn't significantly change functionality, typically bug fixes. (This may allow pre-existing functionality to work properly.) Very likely to be free, otherwise will be covered by the service contract.

A bug fix is an internal description. When released, it would typically be as a patch.

There are software distribution models that don't really conform to this. Web apps can be continuously upgraded without actually releasing anything, and some people like grabbing the source for some of their apps from a publicly available version control system and doing their own compiles. Paul Graham wrote that, in the development of ViaWeb, his startup would announce a new release based on the PR impact rather than any major changes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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