working towards Subsurface 2.0

[Lubomir I. Ivanov]

hello,

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

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

just my 2c...

lubomir
--