Strategy for deprecating packages

bincrafters / community

Central repository for issues and recipes

http://bincrafters.readthedocs.io/en/latest/

MIT License

218 stars 36 forks source link

Strategy for deprecating packages #546

Closed Croydon closed 5 years ago

Croydon commented 5 years ago

AFAIK we don't have a strategy to deprecate packages yet, do we?

There could be several scenarios in which this can happen, e.g.

we maintained a package, which now has official upstream support (e.g. #539)
we maintained a package, which is unmaintained/EOL upstream

How to deal with this, when

a) the package is only in our Bincrafters repository
b) the package is also in conan-center

jgsogo commented 5 years ago

I'm opening a mirrored issue in Conan repo to keep track of this one, but I'm locking it there so no one can add comments to it. Discussion will take place here.

uilianries commented 5 years ago

PEGTL is a good example.

We should keep all packages in bintray, we shouldn't remove any package from bintray because this could break our users.

Also, we should update the recipe with a warning message and update the README file as well.

jgsogo commented 5 years ago

Uploading an alias must be considered too: https://docs.conan.io/en/latest/reference/commands/misc/alias.html#conan-alias

uilianries commented 5 years ago

excellent idea I think

jgsogo commented 5 years ago

Indeed, we could implement the alias making something like this (not tested, but it should work):


class DeprecatedPackage(ConanFile):

    @property
    def alias(self):
        self.out.warn("Package .... is being deprecated. Change yours to require .... instead")
        return "..."

solvingj commented 5 years ago

Yes, alias with warning seems best.

Croydon commented 5 years ago

Agreed. Alias (if there is a replacement) + warning via Conan recipe + git readme + notice on the Bintray page seems fine.

In the cases where there is a replacement, e.g.

we maintained a package, which now has official upstream support (e.g. #539)

I would suggest that we use the first version which has official upstream support as the "soft transition" version. What I mean is, for the case of Catch2:

Catch2 2.5.0 is the first version with official upstream Conan support and publishing/uploading
Bincrafters don't have yet a Catch2 2.5.0 published version
We should upload a 2.5.0 recipe, containing a warning and an alias on the new upstream recipe
Add warnings in the readme, Bintray page, archive GitHub repository
Don't publish any further Catch2 recipes versions in Bincrafters
Leave older recipe versions published by Bincrafters unchanged

uilianries commented 5 years ago

Sounds good, I would change the package icon on Bintray with "deprecated"

example: https://bintray.com/conan-community/conan/Boost%3Aconan

I'm going to work on Catch2 now

uilianries commented 5 years ago

BTW this strategy should be available on https://bincrafters.readthedocs.io/en/latest/

uilianries commented 5 years ago

Hi everyone!

This workflow is now available on https://bincrafters.readthedocs.io/en/latest/contributing_to_packages/package_deprecation.html

Are we good to finish this issue or should we add more information?

Croydon commented 5 years ago

Done from my point of view 👍

solvingj commented 5 years ago

Great work @uilianries

uilianries commented 5 years ago

thanks to @Croydon for providing us his idea :muscle: