Tine subsurface updates

[Jef Driesen]

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