Question: We've recently started using our own internal NuGet server to house packages that are common to many of our internal projects. Originally, every project we work on is versioned with the build date in the format:

```
[Year].[Month].[Day].[DailyBuildCount]

```

However, during our process to upgrade to .NET 4, we've decided to start versioning our packages with SemVer starting with v4.x. The problem is that NuGet treats the v4.x versions as OLDER than the ones versioned with the date format. In addition, projects referencing the v4.x versions think they need to upgrade to the versions with the date format, which aren't even targeting the same framework version.

**Is there some way to configure NuGet such that package upgrades can't cross these versioning lines?**

For inter-package dependencies, we have configured them with specific version dependencies such that dependencies themselves work OK. It's the main project reference that is the issue where "upgrades" may accidentally happen to an older version.

Answer: 
Offhand, I think your best bet is to rename the packages slightly. That will cause them to be considered as completely separate packages and break the version chain altogether.
I have a series of three blog posts that would help you:

* [Performing a safe update using NuGet and Powershell](http://byteflux.me/performing-a-safe-update-using-nuget-and-powershell/)
* [Performing a safe update using NuGet and Powershell with pre-release packages](http://byteflux.me/performing-a-safe-update-using-nuget-and-powershell-with-pre-release-packages/)
* [Coercing the jQuery NuGet package version and downgrading jQuery](http://byteflux.me/coercing-the-jquery-nuget-package-version-and-downgrading-jquery/)

The last link shows an example (in this case jQuery, but can be applied to any package) on how you can coerce the version to a specific range. This will ensure that when you issue an Update-Package command, the project is updated only with references that have a version between a minor and major value).

However, in your case probably the best solution would be as Eric Lloyd suggested before to completely break your dependency chain in order to keep a clean dependency structure.