Breaking change (?) on 0.5.7

[Maj0rT]

Hello,
I think this version should not be v0.5.7 but v1.0.0 as you can read at https://docs.npmjs.com/about-semantic-versioning because the removal of name-table.js sadly breaks the rule "Changes that break backward compatibility".
Currently I have the problem that my gitlab pipeline fails because the 3rd party tool js-ipfs-bitswap uses the dependency "multicodec": "~0.5.0" (which is fine if the backward-compatibility rule will be observed) and relays on that removed source-file.
I believe there will be more projects with the same problem.
Please re-add the file and release it as new version 0.5.8.
Best regards,
Torsten

[hacdias]

Hmmm... how did it break your program? Our tests weren't changed and still work. If you're not using the official API, but importing single files from src/, we cannot have guarantees.

Also, before 1.0.0, every 0.x.0 may be breaking.

[Maj0rT]

It is a transitive dependency by js-ipfs-bitswap. I will call them as well if they can change their code. Am 22. Dezember 2019 16:07:37 schrieb Henrique Dias <notifications@github.com>:

…

Hmmm... how did it break your program? Our tests weren't changed and still work. If you're not using the official API, but importing single files from src/, we cannot have guarantees. Also, before 1.0.0, every 0.x.0 may be breaking. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[hacdias]

Thanks @Maj0rT!

Anyway, I will "invoke" @vmk and @mikeal here just to ask your opinion and give "seniorest" advice: do you consider structural changes to the repository breaking or not? I was not expecting someone to be importing a specific file since we do not support that officially.

And by looking at the code linked from @Maj0rT it seems to have been done ~3 years ago.

[hacdias]

Will be fixed on ipfs/js-ipfs-bitswap#209. Will just reiterate that I don't consider 0.5.7 a breaking change since the API did not change.

[hacdias]

Closing this as the PR above was merged.

[mikeal]

This falls into a big semer grey area for a few reasons.

1. No guarantees are made for breaking changes for version below major 0. This is actually why I tend to start all of my libraries with automated releases at version 1.0.0.

2. name-table wasn’t a publicly exposed API. It wasn’t documented, it wasn’t in the default exports of the packages’s index. It’s only “exposed’ because Node.js exposes every file in a package by default, but you have to import it with multicodecs/src/name-table which certainly looks like an internal rather than external API.

The object was even frozen to avoid people mutating the packages internals. If I was using this, I would expect it to break on me without notice 🤷‍♂️

At the same time, version numbers are free and there are an infinite number of them. IMO, the package should get bumped to 1.0.0 as soon as possible so that we can make the version numbers mean something and err on the side of signaling breaks even when they are this small. There’s no good reason not to given this library’s age and the number of dependents.

[mikeal]

I just realized I wasn’t that clear about what I think the right next steps are ;)

1. I think it was reasonable to consider this a non-major release, but now that we know it might break a few people there no reason we shouldn’t...
2. bump it to 1.0.0 and then deprecate the previous 0.x release. That way anyone who updated to that release will still work but people won’t be getting pushed to that version automatically when they have a fuzzy match on 0.x releases.

[hacdias]

Thank you a lot @mikeal for your opinion. I will release 1.0.0 and deprecate 0.x then. I also agree it's a good idea since we've had basically the same API for quite a long time already.

[achingbrain]

For a change that is not considered breaking, it's broken a lot of stuff!

Maybe you could restore the file for one final 0.5.x release and not have it in 1.x.x?