working towards Subsurface 2.0

[Jef Driesen]

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 
>> if
>> you're interested in (co)maintaining it.
>> But I can already say that the reviewer will complain about the 
>> presence
>> 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 
> Debian
> archive.
>
> How close are we to the stable libdivecomputer API?

We are not there yet. There are several items left on the roadmap [1] 
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 
moment.

On 2012-09-07 00:15, Dirk Hohndel wrote:
> That is currently necessary because of the way libdivecomputer 
> handles
> 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 
> stable,
> 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.

[1] http://www.divesoftware.org/libdc/roadmap.html

Jef