-
Notifications
You must be signed in to change notification settings - Fork 979
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
tiny/minor version compatibility pledge #515
Comments
I already try not to have feature changes between patch releases, only bugfixes. That was the philosophy between all past 0.8.x releases. So who do I need to pledge to and in what form? Can I just keep maintaining Faraday like I did, witch patch releases only containing fixes? Because it doesn't sound like I need to change anything. |
Can you add this information in README? like steveklabnik/request_store#43 But you'll need to release a 1.0 release for stable semver compliance. |
It will be a while until 1.0 because we're still not sure what will go in 1.0. Until then, I'm going to close this because this issue basically asks "can you release 1.0 so we know this is stable". When we're ready to release 1.0, then we'll know it is stable. Until then, the patch releases will signify bug fixes and minor releases will signify API upgrades, just like semver. |
from faraday maintainer ``` I already try not to have feature changes between patch releases, only bugfixes. That was the philosophy between all past 0.8.x releases. When we're ready to release 1.0, then we'll know it is stable. Until then, the patch releases will signify bug fixes and minor releases will signify API upgrades, just like semver. ``` lostisland/faraday#515 (comment) this versioning strategy is the same that is used in the faraday_middleware gem https://github.com/lostisland/faraday_middleware/blob/master/faraday_middleware.gemspec#L16
from faraday maintainer `` I already try not to have feature changes between patch releases, only bugfixes. That was the philosophy between all past 0.8.x releases. When we're ready to release 1.0, then we'll know it is stable. Until then, the patch releases will signify bug fixes and minor releases will signify API upgrades, just like semver. `` lostisland/faraday#515 (comment) this versioning strategy is the same that is used in the faraday_middleware gem https://github.com/lostisland/faraday_middleware/blob/master/faraday_middleware.gemspec#L16
faraday promises compatibility with minor updates lostisland/faraday#515 and many libraries already declare a relaxed requirement.
Currently debian has faraday 0.9.0 but diaspora insist it needs 0.9.1 because they won't support any version change, even bug fixes because it can break things.
Can you pledge to keep compatibility for minor versions? See https://wiki.debian.org/Teams/Ruby/UpstreamPledge
This will guarantee 0.9.x will not break ~> 0.9.0 lock. It would be even better if it was 0.10 won't break ~> 0.9 but that can be considered later, may be after 1.0
The text was updated successfully, but these errors were encountered: