Nudge toward true semantic versioning

[jchand99]

I want to preface this discussion with the fact that is a fantastic package; thank you for your contribution to the svelte community!

With that said, I wanted to bring up the idea of using pure semantic versioning with this package.

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

I noticed the change from version 1.0.3 to 1.0.4 broke the contract between the package and the downstream user by changing the location of some imports from @svelte-router/core/kernel to @svelte-router/core. While I agree with the contents of the change, I think it would constitute a major version number bump (v2.0.0) rather than a patch version number bump from the definition of semantic versioning.

Example: Module federation

In a module federation example, say we have three remotes and a host. Each of these apps all share the @svelte-router/core package as a singleton. Module federation 2.0 states:

If singleton mode is enabled, the shared dependencies between the remote application components and the host application will only be loaded once, and a higher version will be loaded if the versions are inconsistent. A warning will be given for the party with the lower version.
With this in mind, if the host app loads up version 1.0.4, and a remote loads up with 1.0.3, it will actually use the code from 1.0.4, where the imports have been moved, potentially breaking compatibility between the host and a remote just from a patch version upgrade in the host.

Using semantic versioning, the change from 1.0.3 -> 1.0.4 would have been a major version bump, telling the downstream users running the host and remote applications that they should probably synchronize updating to the latest version because it's a major change, which means breaking change.

Curious to hear thoughts on this.

[webJose]

It didn't break the contract. The sub-module is available.

[jchand99]

Ah, you are correct, I didn't think about that fact. Apologies.

[webJose]

No worries. :D I do agree on semantic versioning. I will follow it to the best of my ability. I don't want to use changesets. I'm planning a GH workflow that will prepare the release and increase the version number, which I'm manually doing ATM.

Thanks for the note. Glad you like the router.

P. S.: I thought about using v1.1.0, and call it a "new feature". I guess it would have been OK too.