Package/Assembly version numbers when using multiple frameworks

Sep 20, 2011 at 10:09 PM

Trying to decide how best to handle a library that supports both .Net 3.5 and .Net 4.0.

The 2 versions are not binary compatible (e.g.,the 3.5 version has a Tuple type, whilst the 4.0 does not).

Current options are:

  1. Create separate packages for them, treat them as independent products with their own versioning.
  2. Single package, different version numbers for different frameworks.
  3. Single package, same version number for different frameworks.

1.  Create separate packages for them, treat them as independent products with their own versioning.

This has the advantage of being the simplest option. Whilst each package's version is technically independent, they'll both use the same version numbers to keep them consistent. Thus you would get; Cadenza.net35 containing version 0.85, and Cadenza.net40 containing 0.85. Both of these versions would have been compiled at the same time from the same repository version of the source.

2. Single package, different version numbers.

This clearly identifies the 2 assemblies as being incompatible via semantic versioning but produces some odd version numbers; eg, 10350.0.0.0, and 10400.0.0.0 with a package version 1.0.0.0. Also some people may not be expecting 2 different major versions in the same package, let alone the package version being in no way related to the assembly version.

3. Single package, same version number.

Both packages would use the same version number, or a very similar version number. E.g. 1.0.0.0 for both assemblies and the package, or 1.0.0.350, 1.0.0.400 and  with a package version, 1.0.0. In this the 2 assemblies are viewed as 2 different items, thus it doesn't matter that they do not have semantic version numbers when comparing the 3.5 build to the 4.0 build, as it's considered the equivalent of comparing .Net 2.0 with .Net CF 2.0.

Personally, my favorite is 3 - Single package, same version number.

Sep 20, 2011 at 10:37 PM

When you write 'single package', do you mean single package ID (with possibly different package version), or the exact same package? You also have to think about what happens when you want to update the 4.0 build but not the 3.5.

Sep 21, 2011 at 7:12 AM

To clarify, "2. Single package, different assembly version numbers", and "3. Single package, same assembly version numbers".

Exact same package, as in;

/lib/net35
/lib/net40

Generally, we wouldn't change 4.0 without also changing 3.5.

Hadn't thought about single package ID with different package versions, but that sounds like it would get messy if both were still being updated. I don't really see any other libraries in nuget that have 3.5 and 4.0 as separate packages.

Sep 21, 2011 at 7:20 AM

If you view the 35 and 40 assemblies as being the same version but just targeting different frameworks, then I think #3 is the way to go.

Sep 21, 2011 at 7:31 PM

Yeah, thats sort of what I was thinking. However, a couple of points were raised in discussion that #3 breaks the idea of semantic  versioning, since the 2 dlls are not 100% compatible, yet only vary by a build/revision number.

Looking at System.Version it states:
A difference in build number represents a recompilation of the same source. Different build numbers might be used when the processor, platform, or compiler changes.

So according to that it seems the major, minor and revision should remain the same and the build (3rd number) should change. E.g:

Package: 1.3.0.0
net35: 1.3.3500.0
net40: 1.3.4000.0

Though that then contradicts the idea of semantic versioning that was suggested by, http://blog.davidebbo.com/2011/01/nuget-versioning-part-2-core-algorithm.html.

It does however give the user the least surprise if they check the assembly's version number, since many users probably expect the package version to be similar to the assembly version.

Though since they are not 100% compatible this might cause problems with people upgrading a project from .net 3.5 to .net 4.0, which leads me to thinking it should be separate packages. Though that begs the question, should it use 2 different package names (eg, Cadenza.Net35 and Cadenza.Net40), or the same name but different major versions. If it were using the same name is there anyway to tell nuget that Cadenza.Net35 and Cadenza.Net40 are mutually exclusive (e.g. incompatible versions).

Sep 21, 2011 at 10:50 PM

If you're using the same package ID, then you could never end up with both versions in the same project, since as project can only use one version of a given package. So there is no need to state that they are mutually exclusive.

Sep 21, 2011 at 11:09 PM

I havn't seen an easy way in nuget though to select which version you want of a package?

Sure, you can use the command line, but most users don't, so same package ID but different versions is probably going to be confusing. Hence why I was thinking different package IDs for 3.5 vs 4.0.

Coordinator
Sep 22, 2011 at 1:30 AM
If they're in the same package, the user doesn't have to select the version. NuGet picks the correct version based on the target framework of the project that the package is installed into.
>