-1

Greeting, this is not about issue about the version, but a general discussion about: Why auto increment build version number? Does it serve any practical purpose?

say, I chk in codes 1 month ago, presume the version # is 1.0.0.0

today i rebuild it, same old codes, but ver # is 1.0.123.0

to me, it's the same old assembly compare to 1 month ago, but why different ver?

imo, version number should be auto change only when codes are changed, or any changes that will affect the code behavior.

ps: going to setup TFS, pondering on this

Kelmen
  • 1,053
  • 1
  • 11
  • 24
  • 1
    Well, *something* (or *somebody*) is setting the build number, what does the assembly manifest file look like? I personally believe that the leading triplet should always be explicitly specified.. – user2864740 Sep 17 '15 at 06:49
  • What does your `AssemblyVersion` attribute contents look like? (Also see [this question/answer](http://stackoverflow.com/q/17720008/21567).) – Christian.K Sep 17 '15 at 07:08
  • hi, this is not about issue about the version, but a general discussion – Kelmen Sep 17 '15 at 07:15
  • I would differentiate: Keep the same AssemblyFileVersion (since technically it is the same source (and hopefully same tools - there might be a reason right here to increment anyway)), but mark the fact that is actually a rebuild by putting something like the current date/timestamp into AssemblyInformationalVersion. – Christian.K Sep 17 '15 at 07:26
  • for whatever reason this thread been down-voted, may as well delete it, as i no longer need to bother with tfs – Kelmen Feb 06 '16 at 08:09

1 Answers1

1

It all depends on your criteria for incrementing the version number. The majority sticks to increment at each build rule, because is the simplest to implement, but you can use a different rule. Would be nice to pick a version control identifier (like a Changeset number or Commit Sha) but it is practically impossible to use them except in descriptive places like AssemblyFileInformationalVersion.

That said it is feasible to increment the version number only when the code changes but it requires a certain effort and it starts to get hard soon. E.g.

  • how do you know that the code has changed?
  • where do you store the version numbers after a build succeeds?
  • you track numbers at assembly level or per product/package?
  • different branches have the same version number?

I described an MSBuild/TFS technique in a series of posts (first, second and third). You can see its major drawback: version number live on the build server; if you lose the machine, you have to restore the number serie manually.

You may find other interesting ideas at GitVersion. Here the tool computes the version number on the base of the commit history.

Giulio Vian
  • 8,248
  • 2
  • 33
  • 41
  • how do you know that the code has changed? -> we can rely on the source control, whenever a chk in is committed, just assume there is changes involved. Good source control should able to detect chk in has difference with the repository, if no changes, should just omit the commit, hence no version increment – Kelmen Sep 22 '15 at 03:21
  • It is described in details in the posts: you get only changed files and leverage MSBuild smartness to rebuild only what's needed. – Giulio Vian Jan 27 '16 at 15:46