NuGet Packaging Update Strategies

Following is a list of possible strategies to pursue that could be used to address the issues outlined here.

We've opened an issue here for the community to further discuss ideas re: adopting one of the following strategies, combining one or more of the strategies identified here, or even offering still another strategy altogether.

Strategy 1: Packages Remain as-is today

In this strategy, we literally DO NOTHING. The existing packages remain in NuGet as-is. The existing problems remain.

PRO:

1. no effort required :)

CON:

1. The existing degree of confusion that exists in NuGet will persist unabated.

Strategy 2: Empty Package

In this strategy we update the existing packages (e.g., Common.Logging.NLog) as follows:

1. remove ALL BINARIES from the package
2. update the description of the package to include e.g., "DEPRECATED, DO NOT USE"
3. we provide a readme, etc. in the package that points to this Wiki page that explains the reason the package is deprecated

PRO:

1. including DEPRECATED in the description would catch the eye of at least some subset of adopters and discourage their using the package
2. pointing to the Wiki page would help explain the reasoning behind the change

CON:

1. removing all binaries from the package would break the implicit contract in NuGet that updating a package in-place shouldn't introduce breaking changes
2. While its possible to force NuGet to auto-display a readme.txt on initial ADD of the package, readme.txt files are NOT able to be auto-displayed to the developer on an UPDATE of the package. This means that (most) developers who update to this new "zombie package" won't see the readme.txt unless the go looking for it in their /packages/ folder.

Strategy 3: Wrapper Package

In this strategy, we update the existing packages (e.g., Common.Logging.NLog) as follows:

1. remove ALL BINARIES from the package
2. edit the package dependencies for each package to contain a "pass-through" to the package that targets the "latest version" of each target framework (e.g., Common.Logging.NLog would be a "wrapper package" with a dependency on Common.Logging.NLog31, the "latest version" of the NLog framework at the time of this writing)

PRO:

1. this approach would resolve 100% of the problem of users complaining that e.g. "Common.Logging.NLog needs to be updated"

CON:

1. This approach reintroduces the issue of the developer updating their e.g., Common.Loggin.NLog package and having it "silently" change their logging framework from NLog 2.0 to NLog 3.1 as part of the update process
2. This approach reintroduces the issue of being unable to tell from the package name the version of the target logging platform supported by the package
3. This approach requires update/maintenance of the e.g., Common.Logging.NLog package over time (i.e., when NLog 4.0 is released, Common.Logging.NLog would need to be updated to contain a pointer to Common.Logging.NLog40 instead of Common.Logging.NLog31)

Strategy 4: Update NOOP, Install Warning Package

In this strategy, we update the package and:

1. Leave the binaries intact
2. Set the package icon to a skull & cross bones
3. Update the nuspec description to be a scary "Deprecated do not use"
4. Add the readme to the package that has a similar same scary message.
5. Update the dependencies to specify hard NLog version 1.0.0.505 (not >= version but strict)
6. 4a Update the official packages to have a standard branded icon. See this example
7. 4a Update the official packages to have nuspec tags. eg: tag=nlog for the nlog20, nlog30 packages

PRO:

1. Blind updaters of the dead package will not be affected
2. Confused installers of the dead package will see multiple visual cues in the different icons, readme, nlog references
3. Users searching for "common logging nlog" will discover the nlog20 & nlog30 packages via the tags. Currently, using those search terms does not yield nlog20 packages which is probably the main source of confusion.

CON:

1. None?