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