Archive project?

[Dreamsorcerer]

@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]

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]

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 <#1412 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOLG4VTTSR63P3L4BKF3RDLV4SOSLANCNFSM6AAAAAAQEKL7KY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Dreamsorcerer]

#1413

[Dreamsorcerer]

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]

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]

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]

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]

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]

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]

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.