Shared library versioning scheme has some downsides #309
Replies: 2 comments 1 reply
-
I don't have strong feeling about it, at least not anymore. As of version 3 of the spec the intent for me has been to not do any breaking changes in terms of ability to read a file made by any implementation and I wanted to tie implementations to this fact by using major version 3 but I agree it's problematic in terms of changes that only apply to a specific implementation. I have done the "leap frog" strategy more or less consistently but I agree with that it is also problematic to bump version without changes. |
Beta Was this translation helpful? Give feedback.
-
So I've decided to go with semver per lang and prefixed tags (same name as src dir). |
Beta Was this translation helpful? Give feedback.
-
At some point not so long ago, all the client library versions were unified. I tried and failed to find this discussion on GH, but IIRC the reasoning was approximately: say I write an FGB file with rust 3.25 - what version of the typescript client do I need to be able to read that? It can be confusing to have so many different versions for the same format.
The trouble is, although the clients are intended to read from the same format, they tend to have their own bugs and features thus their own release cadence. e.g. for rust, 3.27.0 was already released: https://crates.io/crates/flatgeobuf/3.27.0, but I don't think any corresponding release has happened for the other clients. (There's no 3.27.0 tag btw)
It seems like the approach we're taking is that each release is typically used by only one client and the other clients would "leap frog" over that release number. Is that right? Otherwise I don't see how we can have a coherent tagging scheme unless we adopt something like a language-prefixed tag like (rust-3.27.0, typescript-3.27.0, etc.)
But there's still problems with that approach. Cargo (rust's package manager) depends on its own kind of semantic versioning to be reflected in the versioning scheme. Probably other languages have similar constraints.
The basic problem is that rust users expect to get non-breaking changes automatically when they run
cargo update
, but in the situation where another client makes a breaking release, because of the unified versioning, the rust client must also make a semantic-version breaking release, even if there are no breaking changes in the rust client. So our users won't get the update until they explicitly bump the version of flatgeobuf they're using.Are there other benefits to the unified versioning thing that I'm not aware of? How would people feel about going back to the old approach, where the clients have independent versioning?
Beta Was this translation helpful? Give feedback.
All reactions