Skip to content
This repository has been archived by the owner on Feb 21, 2023. It is now read-only.

Archive project? #1412

Open
Dreamsorcerer opened this issue Sep 4, 2022 · 10 comments
Open

Archive project? #1412

Dreamsorcerer opened this issue Sep 4, 2022 · 10 comments
Labels

Comments

@Dreamsorcerer
Copy link
Contributor

Dreamsorcerer commented Sep 4, 2022

@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
Copy link
Contributor Author

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
Copy link
Collaborator

Andrew-Chen-Wang commented Sep 4, 2022 via email

@Dreamsorcerer
Copy link
Contributor Author

#1413

@Dreamsorcerer
Copy link
Contributor Author

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
Copy link
Collaborator

Andrew-Chen-Wang commented Oct 20, 2022

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
Copy link
Contributor Author

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
Copy link
Collaborator

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
Copy link
Contributor Author

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
Copy link
Collaborator

seandstewart commented Nov 19, 2022

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
Copy link
Contributor Author

Dreamsorcerer commented Nov 24, 2022

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants