working towards Subsurface 2.0

[Jef Driesen]

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:

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.

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

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

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?

Jef