search

RadicalFx / housekeeping

This repository is intended to keep track and manage all what is not code-related. Requirements and Pre-Requirements discussions should be handled here too.
https://waffle.io/radicalfx/housekeeping
0 stars 1 forks source link

Dependency hell due to `Specific Version == true` #54

Closed mauroservienti closed 8 years ago

mauroservienti commented 8 years ago

The problem is clear, the strange thing is that it surfaced only now and there is no way to reproduce it locally.

Sample scenario:

However

At Radical.Windows.Presentation build time what happens is that Nuget restores the following packages:

Spot the difference? Radical restored version is 1.4.0 and not the referenced 1.3.7, that should not be a problem at all since they are compatible, however the VS solution configuration states Specific Version == true meaning that the referenced assembly version MUST match, thus the failure.

The definitive solution is to completely change, as most of the frameworks/toolkit following SemVer already do, the way we generate the AssemblyVersion. If we follow SemVer, and we do try to, users can safely upgrade within the range of major version, meaning that all 1.*.* are compatible with each other. Given that we can release assemblies where the AssemblyVersion attribute value is always the major version, e.g. 1.0.0, and the AssemblyInformationalVersion contains the real version. This allows Nuget to set, as it should, Specific Version == true, but at the same time dependencies to be updated without requiring a full compilation, since the AssemblyVersion doesn't change.

We can easily achieve this by instructing GitVersion: assembly-versioning-scheme: Major

mauroservienti commented 8 years ago

@micdenny thinking about this more than twice I'd say that this is not a problem at all, and the fact that we encountered this scenario only now after years is just a coincidence, bad luck.

The default GitVersion behavior is assembly-versioning-scheme: Minor meaning that only features change the AssemblyVersion and fixes don't, and to me it is good enough.

We are not a back-end framework where one might be required to release a fix in production without recompiling requiring the assembly level compatibility to be the highest possible. This combined with what should be the default Nuget behavior (Lower) when getting dependencies should do the trick that always worked without issues until today.

So my proposal is to close this and observe what happens while we work in the new CI environment.

micdenny commented 8 years ago

That's fair enough, ok to close and see how it works now