Skip to content
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

Closed
pravi opened this issue Aug 29, 2015 · 3 comments
Closed

tiny/minor version compatibility pledge #515

pravi opened this issue Aug 29, 2015 · 3 comments

Comments

@pravi
Copy link

pravi commented Aug 29, 2015

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

@mislav
Copy link
Contributor

mislav commented Oct 6, 2015

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.

@pravi
Copy link
Author

pravi commented Oct 6, 2015

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.

@mislav
Copy link
Contributor

mislav commented Oct 7, 2015

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.

@mislav mislav closed this as completed Oct 7, 2015
mtyeh411 added a commit to mtyeh411/KahunaClient that referenced this issue Apr 25, 2017
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
mtyeh411 added a commit to mtyeh411/oauth2 that referenced this issue Apr 26, 2017
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
pravi added a commit to pravi/forge-ruby that referenced this issue Jul 27, 2017
faraday promises compatibility with minor updates lostisland/faraday#515 and many libraries already declare a relaxed requirement.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants