Nimble has a 1.0 for Swift 1.2 and 2.0 for Swift 2.
Quick has 0.3.1 for Swift 1.2 and 0.4.0 for Swift 2.
As there is a strong relation between the two they should be versioned similarly.
Also changing from Swift 1.2 to 2 in a minor version update doesn't look right. I know it was the same from Swift 1.1 to 1.2, but I think differentiating Swift language support like it is done with recent Nimble releases is better.
Awesome suggestion, thanks! My two cents (would love to hear other opinions):
As there is a strong relation between the two they should be versioned similarly.
This is a noble goal, but could lead to some silly version changes due to the fact we use semantic versioning for both projects. For example, Nimble may introduce a backwards-incompatible change in order to better serve its users. If we wanted to keep the versions identical, this would cause a version bump in Quick as well, even if nothing had changed at all in that project!
Also changing from Swift 1.2 to 2 in a minor version update doesn't look right.
I think the main issue here is that Quick is still not at v1.0.0. It's fairly stable, but I'd like to merge #304 in before committing to a v1.0.0 API.
I agree with @modocache :+1:
For what it's worth, now that #304 has been merged, I'm planning on tagging a v1.0.0 release. That's just a coincidence, though--I don't think we'll keep Quick and Nimble version numbers consistent. Thanks for the suggestion, though, @rbeeger!
Actually tagging a Swift 2 release of Quick 1.0.0 while Nimble 1.0.0 is targeting Swift 1.2 won't help here either.
Maybe adding a fourth part to the version number that identifies the Swift version as long as Swift is changing so much would help. Something like 1.0.0.swift2 and 1.0.0.swift1_2.
Or somehow making it easy to install the correct constellation of Quick and Nimble via Carthage and CocoaPods could help.
Last week when I downloaded both via Carthage I got a NImble for Swift 1.2 and a Quick for Swift 2.
Theoretically Nimble and Quick are independent from each other, but practically most will either use both or none of them. So maybe having a meta project QuickNimble or something like that would help. You would choose the version of the meta project that works with your Swift and it would pull the right Quick and Nimble via dependencies.
I agree with @modocache. But I do see the user-facing problems with the disparate versions of Quick and Nimble. Would it be acceptable if we're more explicit about the which versions correspond to which versions of Quick on the README / documentation?
@jeffh Putting links to the latest releases for specific Swift versions in the first paragraphs of the READMEs would be a useful compromise.
I agree with @rbeeger, the README should point any user into the right direction in regards to the correct version to choose for each Swift version. Anything else is highly confusing for a new user.
@Zeeker , @rbeeger , @jeffh , I created PR #615 and merged this.
You can see correct version for eash Swift version in https://github.com/Quick/Quick#swift-version 馃槃
That was totally my fault for forgetting to update the README, thanks @takecian! 馃憤
Most helpful comment
@Zeeker , @rbeeger , @jeffh , I created PR #615 and merged this.
You can see correct version for eash Swift version in https://github.com/Quick/Quick#swift-version 馃槃