Specification version about sqids-spec HOT 5 CLOSED

Are you talking about algorithm changes or keeping all languages at the same version?

from sqids-spec.

Algorithm changes, I would assume.

There's a chance that a library would be made later down the line, and it has a 1.0 while the specs are 1.5 for example. Then, for whatever reason, the library is then remade into 2.0 (the changes breaking compatibility with the previous 1.x versions released so far), but the specs never left 1.5 at the time. Reasons why a library could be (but not limited to) having such a change:

• Something about the language changed (like async/await in JavaScript for example) in which a rewrite was wanted enough to not wait for the specs to get updated
• The library was written without considering how the language should have done things, and the maintainers wanted to make it fall in line with that developers in the language would expect (Outside creating this in a language with OOP, I can't think of a reason this would be an issue with how simple the specs are right now)
• It's a plugin to a framework, and the framework had a major number increase that required the plugin to be rewritten for the new version (plugin API for the framework changed, breaking the old code)

from sqids-spec.

That is exactly what I should have written, sorry for that. I had this problem before when we had a spec and several implementations, keeping track of who implements what.

from sqids-spec.

There's zero algorithm changes scheduled for the future unless a critical bug is found (at which point we can discuss how to address this). I'm also not planning on suggesting or introducing any library API changes (encode/decode is pretty much all that's needed).

If implementation-specific repos are doing major changes, they can just follow semver and update users just like any other codebase.

from sqids-spec.

I see your point. If you, in the future reconsider, we discuss how this can be done. Thanks.

from sqids-spec.