Tine subsurface updates
jefdriesen at telenet.be
Thu May 3 02:45:09 PDT 2012
On 2012-05-02 19:35, Linus Torvalds wrote:
> I committed three small changes to subsurface today:
> - it should now compile again with the latest libdivecomputer (yay!
> Another incompatible interface change in LD!)
> Hopefully, it also compiles with older libdivecomputer versions, I
> tried to make it auto-detect the latest interface change (that, btw,
> is not normally possible, so quite often we've had the situation that
> you need to have libdivecomputer match fairly closely in time with
I think there is some misunderstanding and/or miscommunication going on
As you know, I'm well aware of your dissatisfaction with the current
libdivecomputer api, and we already discussed some of the necessary
improvements. I absolutely agree with most of your concerns and will
implement the necessary changes.
I'm already working on some of those changes, along with the other
items on the roadmap [1,2] (namespace prefix, cleanups, etc). This will
be a huge break in backwards compatibility (e.g. the namespace prefix
alone will affect every single function). The original plan was to
bundle all those changes, and introduce them all at once. However this
turns out to be very impractical and slows down the development process.
Therefore I proposed to make an official stable release (v0.1.0) and
then start making incremental changes towards the next stable release
(v0.2.0). During this development phase, the new backwards incompatible
changes will be introduced one by one.
And that's exactly what has happened now. I released version 0.1.0 as
the current stable version, and git master became the development tree
towards the next stable version. The HW Frog change was the first commit
in the development tree, and more will follow. I have even postponed the
frog support until after making the stable release, exactly to avoid
breaking backwards compatibility.
This change in the release strategy and backwards compatibility has
been announced on the libdivecomputer mailinglist , and nobody
objected. So I was actually very surprised to see you are upset with the
frog api break. Especially because this will eventually lead to the api
changes you requested.
Anyway my recommendation for applications is to stick to v0.1.0 for
now, and wait until the next stable release to upgrade. Unless you are
willing to closely follow the development version of course. If bugfixes
are necessary, we can make additional v0.1.x releases, which do maintain
Maybe I should have mentioned this more explicitly when sending out the
announcement email  for the 0.1.0 release. But it was already late,
and I send out a very short email. My apologies for that!
More information about the subsurface