RFC: New api for gas changes

[Dirk Hohndel]

On Wed, Jun 03, 2015 at 04:16:09PM +0200, Jef Driesen wrote:
> On 2015-05-22 17:49, Dirk Hohndel wrote:
> >Life could be so much easier if you did the one simple thing that Linus
> >and I have suggested quite a few time which would allow applications to
> >detect which features are in the version of libdivecomputer that they are
> >building against and which aren't. Your vision of doing this has always
> >been in the context of "releases", assuming that the consumers of
> >libdivecomputer won't be building against master - but that just isn't how
> >many people appear to be using libdivecomputer. And because all the
> >constants are enums and not defines, there is no easy way to test what's
> >there and what isn't.
> 
> In most software projects, you are supposed to use "releases", and not
> development versions. Unless you are developer and want to try the bleeding
> edge of course. Libdivecomputer is no different in that regard.

If one uses the release versions only, one usually misses out on a lot of
the most recent fixes.

> While I understand your arguments, introducing a detection macro for every
> single feature that gets added or changed during the *development* cycle,
> also means I have to maintain those forever, even after the release. [As a
> side note: what's the point of doing releases if you're always going to rely
> on feature detection macros?] But they are not a perfect solution either.
> For example with the DC_FIELD_TANK api, the interpretation of the volume
> field of the dc_tank_t struct has been changed in an incompatible way. You
> won't be able to catch such changes with the presence of a simple
> DC_FIELD_TANK macro.
> 
> I guess the relevant question here is: why is everyone using the master
> branch right now? The answer is probably because the next release has been
> delayed several times already now. The previous release was more than a year
> ago, so you basically need master to take advantage of some new features
> that should have been released long ago.

Yep

> I actually intended to do shorter
> release cycles (e.g. every 3-4 months). Unfortunately some of the features
> that I wanted in v0.5 are taking me much longer than expected. I'm not
> really satisfied with this situation either!

And what I'm telling you is that releases really don't matter for me that
much. I'm now bundling libdivecomputer with Subsurface and that means I
don't assume that people will use Subsurface together with a random
release of libdivecomputer.

> Now, let's assume for a moment that libdivecomputer would have more frequent
> releases. Would you still be using the master branch for subsurface builds?

Almost certainly.

> For the stable branches, the DC_VERSION_CHECK macro should do the trick just
> fine. And when building against master (in order to try the latest stuff,
> and not some feature that should have been released long ago, like is the
> case now), I don't think it's unreasonable to require the latest version.
> Right?

Yes it is. That's why I'm bundling it now. People want to run Subsurface
on ancient distributions. We still support Ubuntu 12.04 for example (that
will be dropped in 4.5, though).

> How about doing the long awaited v0.5 release now? It won't have all the
> features that I originally planned. But instead of waiting until everything
> is finally ready, I just make a few (smaller) intermediate releases.

That's entirely up to you. At this point my plan is to continue to base
the Subsurface-testing and Subsurface-x.y branches on master. And as I am
bundling them with a Subsurface release all I need to make sure is that
they match.

For the Subsurface developers it means that they need to track my
branches, but I think that's what most of them do, anyway.

/D