2

What I'm asking is maybe a little weird but is there any rule in changing your .NET program version when you're adding new features?

To be more clear:

  • You have your initial C# program and you add a few new features to it.
  • Your initial version was 1.0.0.0, but you update it to 1.1.0.0

Is that how it works? Or does it also has to do with how bigger the change?

Example:

  1. Changed whole UI design (v1.0.0.0 updates to v1.1.0.0)
  2. Fixed a little bug (v1.0.0.0 updates to v1.0.0.1)

Any answer would be very welcome!!

rene
  • 37,946
  • 78
  • 99
  • 132
Selrygoxeser
  • 85
  • 7

2 Answers2

11

Use semantic versioning:

Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards-compatible manner, and
  3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

See http://semver.org/ for more details.

In terms of UI it's a little more gray. I would argue wholesale changes to the interface should be classed as major but adding or tweaking a few layouts be classed as minor.

Community
  • 1
  • 1
Lloyd
  • 27,966
  • 4
  • 78
  • 91
  • If I have `1.9` version and I want to release new version that is backwards-compatible then should it be `1.10` or `2.0`? `1.10` looks a little weird to me, but based on your answer it seems to be correct approach. Am I right? – FCin Sep 10 '17 at 14:31
  • 1.10 is correct – Brandon Minnick Sep 10 '17 at 14:37
1

Come up with a versioning scheme that fits your program. There are plenty of tools when you get into build automation that can increment parts of your version. I have done all of the following in my professional work:

  • Only ever incrementing major/minor at the order of management, because advertisement was based on version X.X coming out "next"
    • This was also important since new features always went to a forward version, but we would backport bugfixes to some previous releases, which WOULD increment their third number. Thus, 4.2.3.x might actually be "newer" than 4.3.2.x but would lack 4.3 features.
  • Padding the third or fourth component in order to prevent sorting confusion when seeing x.x.x.0021 versus x.x.x.0100
  • Using the fourth number as the SVN commit number, making version lookups a complete breeze during bug reproduction
  • Making the third or fourth number autoincrement on every automated build, especially useful when you have an autoupdate component and a CI system like Jenkins or TeamCity
  • Using a "special" identifier for build/release versions; specifically using a 666 in the third or fourth number for dev versions as a sort of "warning"

My ultimate point is that while there are general guidelines out there and you should absolutely upvote Lloyd for pointing out the ones on MSDN, be aware that the requirements of your project, management, or pipeline will often have a heavy influence on your versioning scheme,. and it's more important to come up with something and stick to it.

David
  • 9,863
  • 1
  • 23
  • 39