working towards Subsurface 2.0

[Jef Driesen]

On 2012-09-07 15:14, Lubomir I. Ivanov wrote:
> On 7 September 2012 15:23, Jef Driesen <jefdriesen at telenet.be> wrote:
>>
>> 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.
>
> i think the version increment (+tags) when API changes / breaks is
> generally a good idea and that is a pretty clear signal for package
> maintainers and app developers.
> in my opinion it should be updated less often, since often, will
> scatter the development process of applications that are actually
> using the library.
> less often would mean: "ok, libdivecompuiter will soon release a new
> 0.x increment. lets reserve time for making the changes in our app."

If I could, I would just introduce all the changes, all at once. 
Unfortunately I can only work on libdivecomputer in my (limited) spare 
time, so everything takes a bit longer and I'm doing it step by step.

>> 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.
>>
>
> i don't really think they are many magical solutions to that. :-(
> if a bug is muffled under API incompatibility between the master /
> stable branches it still has to be addressed in one way or another
> (from my experience mostly manually...if patches don't work). perhaps
> someone could help you with this (i.e. maintaining the stable 
> branch),
> so that you can focus on "master" ?

I wouldn't mind some extra help.

Jef