working towards Subsurface 2.0

Dirk Hohndel dirk at hohndel.org
Fri Sep 7 06:47:22 PDT 2012


On Sep 7, 2012, at 5:23 AM, Jef Driesen wrote:

> 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.

I agree this would be the sane approach, but we already require a newer version than 0.1 for subsurface.

And last time I checked subsurface was the only Linux program that used libdivecomputer :-)

> 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?

It certainly would help us. It would be great if we could have a 0.2 release of libdivecomputer that we could require for subsurface 2.0

> 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.

yes, that would be a huge improvement.

> 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 bug fixes.

There are a number of options. You could deprecate older branches. Or you could limit the number of release bumps that you do by bunching the incompatible changes closer together.

/D


More information about the subsurface mailing list