Version number scheme

Feb 18, 2011 at 11:20 AM

We're currently using a version scheme. This scheme has some nice advantages:

  • See immediately how old an assembly is
  • Fully automatic
  • We don't want to care about versions
  • We work incrementally in small steps and usually don't break stuff (but use Obsolete to tell dev's about breaking changes)
  • We don't need the flexibility because we don't patch older versions anyway (just fixing builds in mainline, causing a new version)

Yet in the context of NuGet, the classical version format (major/minor/revision) does have some advantages as well:

  • Semantics: minor number changes are expected to be backwards compatible, revision number is essentially for specific bugfixes (without bringing in other changes)
  • NuGet, OpenWrap etc. actually are smart enough (and getting smarter) to use that semantic data e.g. when two dependencies both depend on a package but with different version
  • We would get more flexibility (e.g. for bug fixing and old version) in case we'd actually need it at some point in the future
  • Being more "standard"

I'm fine with both approaches, yet we might get into trouble when we want to change the approach later and try to make NuGet recognize "MathNet.Numerics-2.0" as newer than "MathNet.Numerics-2011.01.02.213"

What do you think?


Feb 18, 2011 at 11:39 AM

I'm partial to date based versions, but have no problem using the more standard version if it makes setting up NuGet easier.


Feb 18, 2011 at 11:59 AM

So am I. Date based also has the additional advantage that we don't have to change anything ;)

I'll try to continue with date-based versions.