-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bump major version for non-backward compatible API changes #323
Comments
I actually see now that 1.3.5 already has some breaking API changes (e.g. signature of the |
1.3.4 (maybe even 1.3.3) also had some Breaking changes regarding Exception names. It would be very cool to know whether harvesters does not intend to follow semver or if this has just been a small oversight. |
@StefanD986 Hi Stefan, thank you for giving me an opportunity to learn about semantic versioning. It is true that 1.3.4 and 1.3.5 contain changes that break backward incompatibility so I am planning to yank the 1.3.5 package from PyPI and release 1.3.6 that gets the dropped ones back. |
@Gornoka Hi,
Do you mean the line above can cause the ImportError? Could you show me the output from:
Those exceptions are from |
@StefanD986 Hi, I have just pushed the change to the following branch: In the branch, I have gotten the dropped public API back; no change in their deprecation status. If you can happy with that, I will merge it into the master and release it as 1.3.6 soon. This is just for your information, version 1.3.5 has been dropped from PyPI. Regards, Kazunari. |
Great! I looked through it and tried it with our application and it works again. Thanks for the quick action. |
@StefanD986 Hi Stefan, thank you for giving that a try, and for giving me an opportunity to bring up the perspective of dependency maintainability into my project. I appreciate that. Regards, Kazunari. |
I saw in the code that some methods are deprecated in 1.3.5 with the comment stating that they will be removed in 1.4.0. If they are indeed removed in harvesters 1.4.x would not be backward compatible with code that used harvesters 1.3.x.
I am not sure whether Harvesters follows semantic versioning guidelines, but if indeed it is, then technically a non-backwards compatible change in the API should cause a bump of the major version number (=> bump to 2.x).
Otherwise this might cause some surprise in projects that depend on Harvesters and pinned the version to 1.x to allow for feature upgrades but prevent accidental breaking updates.
The text was updated successfully, but these errors were encountered: