RFC: New api for gas changes

[Jef Driesen]

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.

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

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

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.

>> They will still build, but they will no longer get any gas change 
>> events. In
>> order to maintain backwards compatibility, I'm planning to introduce 
>> the new
>> api as follows: The old events will get marked as deprecated, but not
>> removed yet. That ensures existing applications will continue to work 
>> with
>> no changes. In the meantime, applications can start to use the new 
>> api. And
>> once v0.5 is out, the old events will be removed.
> 
> But that's not what the patches below do, is it? They just remove 
> support
> for the old event from the backends.
> 
> I'd rather have you do what you describe here - support both for a 
> while,
> but make it possible to detect if the new SAMPLE type is available 
> (which
> then allows the app to ignore the deprecated events).

I started working on these patches several months ago. At that time, the 
plan was still to introduce them after the v0.5 release. That's why the 
attached patches do indeed remove support for the old events. But don't 
worry, I'll make sure that the old events are restored before applying 
them. Sorry, for the confusion. I should have mentioned that more 
explicitly.

Jef