search

aio-libs-abandoned / aioredis-py

asyncio (PEP 3156) Redis support
https://aioredis.readthedocs.io/
MIT License
2.3k stars 336 forks source link

Archive project? #1412

Open Dreamsorcerer opened 2 years ago

Dreamsorcerer commented 2 years ago

@Andrew-Chen-Wang What's the current state of this repo? Doesn't appear to have been any activity since merging into redis-py, so shall I archive the repo now? Are there any PRs/issues that need to be migrated over or anything?

Dreamsorcerer commented 2 years ago

I'd suggest pushing 1 more release that included a deprecation warning on import though. To help ensure that all users are aware of the change.

Andrew-Chen-Wang commented 2 years ago

I suggested we could maybe revert the 2.0 change back to 1.3.1 and bump it to version 3, but that might be confusing. Thoughts?

I’m leaning towards deprecation notice on import and a README note specifying who to contact if they want the package name. But having aioredis archived is also not a bad idea.

On Sun, Sep 4, 2022 at 9:18 AM Sam Bull @.***> wrote:

I'd suggest pushing 1 more release that included a deprecation warning on import though. To help ensure that all users are aware of the change.

— Reply to this email directly, view it on GitHub https://github.com/aio-libs/aioredis-py/issues/1412#issuecomment-1236339987, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOLG4VTTSR63P3L4BKF3RDLV4SOSLANCNFSM6AAAAAAQEKL7KY . You are receiving this because you were mentioned.Message ID: @.***>

Dreamsorcerer commented 2 years ago

1413

Dreamsorcerer commented 2 years ago

I suggested we could maybe revert the 2.0 change back to 1.3.1 and bump it to version 3, but that might be confusing.

I'm not familiar with the 2.0 change, but, would that cause problems for users who are already using v2? Could always push 2 deprecation updates, a 2.0.2 and a 1.3.2 release.

Andrew-Chen-Wang commented 2 years ago

2.0 change was for the redis-py port, but that is now in the redis-py package itself. I think a deprecation notice for both major version is a good idea.

I'm htinking 3.0 will be the exact same as 1.3.1 (where the original maintainer last left it), then we can push a 3.1.0 change with the additional changes seandsteward and I merged later on.

Dreamsorcerer commented 2 years ago

I'm htinking 3.0 will be the exact same as 1.3.1 (where the original maintainer last left it), then we can push a 3.1.0 change with the additional changes seandsteward and I merged later on.

Wouldn't that mean people who already upgraded to v2 will have problems with v3? I'm not really sure why a v3 is needed.

Andrew-Chen-Wang commented 1 year ago

For those who used v2, they should be migrating to redis-py now, as mentioned in the README today.

For v3, it would be the original aioredis.

Dreamsorcerer commented 1 year ago

If they've not migrated to v2, then they can just stay on v1 for now (likely they have it pinned as <2). Whenever they decide to update to a new major release, they should move to redis-py. I still think a v3 is likely to cause issues.

seandstewart commented 1 year ago

I think at this point, we can simply leave a note on the readme pointing folks to redis-py and archive this repository and the PyPI package.

@Andrew-Chen-Wang - if you're happy with that, I'll move forward with it. If you'll manage updating the repo, bumping a patch version, and publishing to PyPI, then I'll manage archiving the package on PyPI once it's done. Maybe add an import-time DeprecationWarning to boot.

Dreamsorcerer commented 1 year ago

I think a 1.x Deprecation is probably irrelevant anyway. Anyone on 1.x should already know they need to upgrade to 2.x, and will discover the project is archived at that time. A 2.x DeprecationWarning would still be nice (I've just found aioredis still being used in my new job), but I'll leave it to you guys to decide what to do.