For example libgnome-desktop doesn’t have API stability guarantees. I have switched Tepl to such model too instead of incrementing frequently the major version number.
Since it’s a good idea to drop the even/odd scheme, I wondered if there is a better keyword than e.g. “alpha” to mark that a library always has an unstable API, even when releasing for use by a stable version of an application.
The idea is to easily distinguish libraries that have API stability versus those that don’t. Those that don’t would always have the keyword attached to the version number.
“alpha”, “beta” or “rc” are not great in that case. Maybe “dev”, “dev-snapshot” or just “snapshot”? With “unstable” some people may think that it’s alpha quality.
Any ideas? Is it worth doing something about it? Are there already well established conventions in some Linux distros packages?
tepl-6-0 is currently the latest stable branch, the API/ABI will not break on that branch.
Then in the future, the Tepl library is more meant to be bundled and API stability is no longer guaranteed within the same major version (which is still 6).
I just wondered if there is a convention for the version numbers/names, in addition to the soname solution.
Anyway, Tepl is no longer a core dep. It’s just that gedit uses it (and other projects).
Quoting the Tepl introduction:
Tepl contains more experimental APIs than GtkSourceView, sometimes even
unfinished features. API design is hard, it needs an iterative process.
Instead of being stuck for years with a non-optimal API, the Tepl
developers want to be able to break the API at any time, to iteratively
improve it. Sometimes we see possible improvements several years later.
Ideally projects like gedit should ship Tepl as part of their tarballs, it would avoid the problem altogether. But I know distributions like Debian doesn’t like bundling.