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

[chrisballinger]

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: 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]

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]

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]

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