Remove Analyzer meta-package in 5.0.0

[blairconrad]

There's no need to subscribe to an analyzer that examines both C# and VB code.

[blairconrad]

Anyone know what the best practice around removing a package is? Do we replace it with a README, or just leave the subscribers stuck on the old version?

[thomaslevesque]

Anyone know what the best practice around removing a package is? Do we replace it with a README, or just leave the subscribers stuck on the old version?

Is it even possible to replace with a README? At some point, Json.NET showed a readme file upon install, but I think it's no longer possible.
I think we could just unlist it and stop updating it.

[thomaslevesque]

Or publish an update with a fake warning that tells the user to switch to the language specific package.

[blairconrad]

You mean a diagnostic that would fire with that message?

[thomaslevesque]

It was my first thought. But now I think it could just be a MSBuild warning. The package would just contain a MSBuild file that would emit this warning.

[thomaslevesque]

The only problem I see with this approach is that ideally, the package would have to be unlisted so that people don't install it by accident... but if it's unlisted, people using the previous version won't get the update.

[thomaslevesque]

I have a working prototype, with a target like this:

<Project>

    <Target Name="WarnAboutWrongAnalyzerPackage" AfterTargets="AfterBuild">
        <Warning Text="The FakeItEasy.Analyzer package is no longer maintained and does nothing. Use the C# specific analyzer package instead: FakeItEasy.Analyzer.CSharp."
                 Condition=" '$(Language)' == 'C#' " />
        <Warning Text="The FakeItEasy.Analyzer package is no longer maintained and does nothing. Use the VB.NET specific analyzer package instead: FakeItEasy.Analyzer.VisualBasic."
                 Condition=" '$(Language)' == 'VB' " />
    </Target>

</Project>

The package version will be fixed to 5.0.0.

However I wonder how to handle it in the build, since we only need to do it once. Deployment will work the first time, but we'll have to disable deployment of this package afterwards, since an existing package can't be redeployed with the same version.

[thomaslevesque]

Maybe we should just deploy it manually and forget about it...

[blairconrad]

I love it.
And yes, I think manually deploying once and removing the package from our repo once we hit 5.0.0 is perfect.

[thomaslevesque]

This could be useful, unfortunately it's not ready yet...

https://github.com/NuGet/Home/wiki/Deprecate-packages

[thomaslevesque]

The nuspec and targets for the new package (to be built and deployed manually when we release 5.0.0) can be found here: https://gist.github.com/thomaslevesque/289b9f917a129890bed04dd0320e10b1

[thomaslevesque]

This change has been released in FakeItEasy 5.0.0.