Hi,
For those not on the subsurface mailinglist, you can read the first part of this discussion here:
http://lists.hohndel.org/pipermail/subsurface/2012-May/000208.html
On 2012-05-03 17:58, Linus Torvalds wrote:
It's the *ugly* and pointless breakage that I get so upset about. It makes things harder for everybody for no actual reason. And it is indicative of the same old "I don't think of libdivecomputer as a library, I think of it as a random collection of internal routines" problem.
Interfaces are important. Even during development. They are doubly important when it's a library that other projects use.
Let's try to approach this discussion from another perspective.
In the past, the libdivecomputer library provided no official releases, and there was just a single development branch (git master) where all the work was done. This development model didn't work well for applications, and therefore I introduced the new model with the 0.1.0 release. My idea was to proceed as follows:
1. We keep git master as the main development branch. This is where all the work towards the next stable release happens. New features can be introduced and backwards compatibility isn't guaranteed.
2. Stable releases (e.g. v0.x.0) are provided at the end of each development cycle.
3. Whenever bugfixes for a stable release are necessary, a new release branch is created. Only bugfixes are allowed here, and backwards compatibility is maintained. Releases from this branch will increment the micro number only (e.g. v0.x.y).
This development model would allow me to introduce backwards-incompatible changes incrementally and also faster (e.g. no need to delay breaking changes). Applications should stick to the stable releases, and therefore require updating only when upgrading to the next stable release. Any incompatible changes will be documented with the new release. No more unexpected breaks anymore. Support for older versions can be kept by conditional compilation based on the libdivecomputer version macros.
I assumed this would be a huge improvement compared to the previous situation, because it keeps the pain for applications to a minimum, while still providing enough flexibility to commit work-in-progress to the development branch. At some point, once we're all satisfied with the public api, we can move to v1.0.0 and never break backwards compatibility again. But let's concentrate on the road towards that goal first.
If you (or anyone else) think this is not the right way to proceed, please tell me what you would do different.
Jef