Diamonds Aren’t Forever – Choosing a package update strategy

There are two distinct yet related parts in the automatic creation of a package that need to be considered.

  1. Updating of its dependencies for building

    Should we always update to the latest versions of our dependencies before building?
    Or only up to the latest minor version? Or Major version?
    Should we specify ranges for each individual package that we should update to?

    Nuget provides two options here, one is too specify (by hand ATM) the allowedVersions attribute in the packages.config (following the Version Specification). The update command then only updates to versions that are within the specified range.

    At the moment, the Nuget pack command doesn’t copy these across into the package. So this needs to be automated manually.
    (This should be fixed in the next version)

    The other option is to use the –safe option of Update. From the docs “Looks for updates with the highest version available within the same major and minor version as the installed package.”.

    In other words, if you have Elmah 1.0.0.0 installed, and 1.0.1.0, 1.0.2.0, and 1.1.0.0 are in the feed:

    Command Description
    Update-Package Elmah Updates Elmah to 1.1.0.0
    Update-Package Elmah -Safe Updates Elmah to 1.0.2.0

     

  2. Specifying allowable dependency versions during packaging?

    Should we restrict consumers to only using the exact version of our dependencies that we built with?
    Or should we allow any new version to be included?

    At the moment NuGet Pack adds dependencies from your project file with no version restrictions. So any consumers of your package can upgrade to newer versions of your dependencies. Any restriction you require will need to be done via custom build step to customise the dependencies or manually maintain a nuspec template that pack will use.

    I have created an MsBuild target called LockVersionDependencies . Which will lock dependency versions to the exact version used to build the package.

These are interrelated issues;  regardless whether your package is happy to upgrade to the latest of every dependency, those dependencies may restrict the allowable versions of other dependencies to an exact version or a restricted range.

My Preference

I prefer to allow all dependencies to update to the latest version during the build. If it’s successful I lock the dependencies to the exact version I built with when I create the package; so downstream builds will only use a combination of versions I know have built and passed the tests.

If a dependency updates and breaks the build, I would then fix the issue, or specify a version restriction for it so it doesn’t upgrade in future builds.

Advertisements
Tagged , , ,

2 thoughts on “Diamonds Aren’t Forever – Choosing a package update strategy

  1. […] Picking an Update Packages Strategy […]

  2. […] Packages Build step found here. It will also use my preferred Package Update Strategy defined here. The build targets are specified in the build directory of the solution (here) The build targets are […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: