search

johnpatrickmorgan / FlowStacks

FlowStacks allows you to hoist SwiftUI navigation and presentation state into a Coordinator
MIT License
854 stars 66 forks source link

Semantic versioning issue - 0.1.7 has breaking changes, consider releasing as 0.2.0 instead #20

Closed chrisballinger closed 2 years ago

chrisballinger commented 2 years ago

Hey! I just wanted to start by saying that this library is great and I have pointed a lot of folks in your direction who are looking for a better approach to navigation in SwiftUI.

We currently pinned to "upToNextMinor" and had some code that was still using the deprecated NStack/PStack, which looks to be removed in the 0.1.6->0.1.7 release: https://github.com/johnpatrickmorgan/FlowStacks/compare/0.1.6...0.1.7

It looks like some CI system of ours automatically bumped the patch version assuming it was "safe" to do so, and it broke the build.

I know that the 0.1.x implies that there will be some API instability, but I'd suggest at least bumping the minor version when making breaking changes that might require folks to undertake a bigger refactor. Normally I'd suggest pulling the 0.1.7 release and re-tagging it as 0.2.0 - but it's been out for 2 days now and that might cause even further issues if people's Package.resolved are pointing to that version now.

Just wanted to flag this here for other folks who might be encountering this as well.

Cheers!

johnpatrickmorgan commented 2 years ago

Thanks @chrisballinger, and glad you're getting good use out of the library. You're totally right - a minor version change would have made much more sense for that breaking change.

As you say, it might cause problems to amend the tag now, but I suppose I could revert the change in a version 0.1.8 and remove them again in a version 0.2.0. That should minimise the impact on anyone else in the same situation.

Sorry for the inconvenience!

chrisballinger commented 2 years ago

No worries! Was able to get a workaround in place, which revealed some other problems about why the Package.resolved file wasn't in source control. If it wasn't this breaking change, it was gonna be some other library down the road causing issues.

That 0.1.8/0.2.0 approach sounds like a good idea!

chrisballinger commented 2 years ago

Resolved via 0c2a791 / 5a1d58a and 0.1.8 / 0.2.0. Thank you!