working towards Subsurface 2.0

[Dirk Hohndel]

On Sep 10, 2012, at 12:44 AM, Jef Driesen wrote:

> On 2012-09-07 15:47, Dirk Hohndel wrote:
>> On Sep 7, 2012, at 5:23 AM, Jef Driesen wrote:
>>> On 2012-09-07 02:45, Roland Dreier wrote:
>>>> 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 :-)
> 
> That's not entirely correct. Diveboard (an online logbook with a libdivecomputer based browser plugin), kenozooid and DiverSuite are also available for Linux. They are just not available from the distro repositories (I think). I try to maintain a list of libdivecomputer based applications here:

Oops - I stand corrected. I simply remember Linus and I searching for Linux dive log programs before the work started and nothing seemed even remotely useful :-)

> http://www.divesoftware.org/libdc/links.html#applications
> 
>>> 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
> 
> Let me know when the subsurface 2.0 is almost ready to be released, and then I'll prepare a libdivecomputer 0.2 release. I don't have any backwards incompatible changes planned for the next few weeks.

The plan had been to release 2.0 in the next few weeks - but obviously we need to work on fixing the outstanding bugs and completing the features that we started (e.g. the default file / last file / multi user issue).

>>> 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.
> 
> Ok, then that's what I'll do.

Thank you.

>>> 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.
> 
> I have been doing grouped changes already since the v0.1 release. For example I did commit the dc_context_t changes only after everything was ready. But there will always be some time in between, until the next incompatible feature has been implemented. I don't want to postpone too much, because then nobody can have a look at it and provide feedback. So I try to bundle changes as much as possible, but I can't bundle them all.

Of course not, and that's fine. I was simply trying to help you figure out a good middle ground - and make sure that the people volunteering to package subsurface and libdivecomputer for the distros have a reasonably doable task :-)

> Committing bugfixes only to the most recent stable branch sounds fine. Maybe also maintain the stable 0.1 branch for a while, for those who don't want to deal with api changes at all, until the final interface is in place?

That sounds very reasonable.

/D