working towards Subsurface 2.0
jefdriesen at telenet.be
Fri Sep 7 05:23:27 PDT 2012
On 2012-09-07 02:45, Roland Dreier wrote:
> On Thu, Sep 6, 2012 at 2:52 PM, Pierre-Yves Chibon
>> I can help on this one for Fedora for both libdivecomputer and
>> subsurface. I can also help to get someone into the packager group
>> you're interested in (co)maintaining it.
>> But I can already say that the reviewer will complain about the
>> of the -static sub-package containing the .la file.
> Likewise I'm a Debian maintainer but I think the static copy of
> libdivecomputer is a hurdle to getting subsurface into the real
> How close are we to the stable libdivecomputer API?
We are not there yet. There are several items left on the roadmap 
that will have a significant impact on the public interface. Especially
the cleanup of the parser api (#6), and the transition to a dive based
interfaced (#23). There is still a lot of work do be done there.
I think distributions should ship the stable v0.1 release. Shipping
from the work-in-progress master branch will definitely create a lot of
trouble once two or more applications each require incompatible
versions. The release-0.1 branch is guaranteed to receive bugfixes only.
For an application like subsurface, which requires a development
snapshot, I think static linking is the only viable option at the
On 2012-09-07 00:15, Dirk Hohndel wrote:
> That is currently necessary because of the way libdivecomputer
> API compatibility until it hits 1.0 (basically, until 1.0 Jef will
> continue to break API compatibility with the intent to get to a
> longer term compatible API for 1.0 - and at least so far this has not
> been detectable from the makefile or packaging software as version
> numbers didn't correspond to breakage). This is unfortunate but since
> changes to libdivecomputer do indeed break the subsurface build from
> time to time, I don't think this is easily avoidable at this point.
Dirk summarized it pretty well. The libdivecomputer master branch is a
development branch and will break backwards compatibility from time to
time to reach a stable api in the long term. If anyone has suggestions
to reduce the amount of trouble this causes, I'm listening.
Would it help if I made v0.x releases more frequently? Right now, we
are working towards the next v0.2 release, but I haven't really defined
fixed milestones for these intermediate v0.x releases. Does it makes
sense to make a new v0.x release before introducing each (or at least
the start of a few) backwards incompatible change? Let's say I release
v0.2 now. Then subsurface (and distributions too) can stick to this
version for a while. The next round of backwards incompatible changes
will then go into v0.3, and so on. The main advantage would be that you
could rely on a specific version number instead of a specific commit.
The only thing, I'm not so sure about is how to handle bugfixes on the
stable branches. With just one development branch (master) and one
stable branch (release-0.1), I can handle backporting bugfixes to the
stable branch. (So far I have been doing bugfixes exclusively on the
stable branch, and then merge them into master from time to time.) But
if there would be many more intermediate release, I don't want to spend
my time on backporting every single bugfix to each stable branch. It's
just takes to much of my time, that I would rather spend on reaching the
stable api. Basically this would mean there will be only v0.x tags, but
no corresponding release-0.x branch for bugfixes.
More information about the subsurface