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

1.3 violates semantic versioning #87

Open
solidfox opened this issue Sep 19, 2016 · 7 comments
Open

1.3 violates semantic versioning #87

solidfox opened this issue Sep 19, 2016 · 7 comments

Comments

@solidfox
Copy link

1.3 includes a load of breaking changes and thus should increase the major version of the library.

http://semver.org

@tomvanzummeren
Copy link
Owner

Sorry.

@solidfox
Copy link
Author

No worries, just thought I'd tell you before a lot of product owners start complaining about compile errors. Thanks for a great framework!

@chamander
Copy link

I'm finding this as well, Tom.

Are there any intentions to fix this to remove 1.3.0?

@tomvanzummeren
Copy link
Owner

I don't see what the big deal is. It is just a number. Use 1.2.0 for Swift 2 and 1.3.0 for Swift 3. Done.

@chamander
Copy link

Using Carthage as an example:

With the way dependencies are worked out, artifacts such as ~> 1.2.0 will resolve to any version up to, but not including 2.0.0, so projects that are dependent on your work will pull 1.3.0 if they have specified ~> 1.2.0.

This means that any projects expecting compatibility for any 1.x.x build up to version 2.0.0 don't actually get it--even though your API may not have changed.

This deters implementers from running

carthage update

to seek patch version updates that might fix issues with the library and encourages

github "tomvanzummeren/TZStackView" == 1.2.0

Integration gets a little more difficult--less straightforward.

I understand if you feel this doesn't warrant action.

Thank you for the framework; I hope I can help by contributing, some day. 🙂

@tomvanzummeren
Copy link
Owner

Ok, next time I will do this properly. For now the 'damage' is done and I am also not sure if I can delete a Cocoapod version.

@tomvanzummeren
Copy link
Owner

You're welcome to contribute by the way, but there is not much to be done. This framework is almost obsolete anyway, since less than 10% run iOS 8 right now.

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

3 participants