RFC: New api for gas changes

[Jef Driesen]

On 03-06-15 16:54, Linus Torvalds wrote:
> On Wed, Jun 3, 2015 at 7:16 AM, Jef Driesen <jef at libdivecomputer.org> wrote:
>>
>> 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.
>
> Jef, your releases haven't been timely enough to use, and they aren't
> any simpler to distinguish _either_.

I assume you are referring to the features in a release, and not the version 
itself? Because that's easy to check with DC_VERSION_CHECK and friends.

> If you were to make releases much more often, and if those releases
> had clear ways to test for features, your argument would be stronger.
> As ti is, people pretty much *have* to use non-release versions.
>
> Your last release was what, 15 months ago?
>
> So don't tell people to use releases, when you then make it a
> non-option. If you expect people to primarily use released versions,
> you need to release them _much_ more often. Several times a year, not
> "every year or two".
>
> I think one of the issues is that you have these "big features" you
> want to get done, and that is always a problem for release timing. I
> used to do that with the kernel too (_years_ between 2.4 and 2.6
> stable releases), but even back then I did "developer releases" much
> more often, and would encourage people to use them.
>
> The whole "make a release every two or three months, whether things
> have changed a lot or not" makes things much easier both as a
> developer (no "big plans" to worry about, no lack of testing in
> between big changes etc) and as a user (no huge jumps). I can heartily
> recommend it.

Yeah, I know it's been *way* too long. I intended to do shorter release cycles. 
But because I wanted to introduce some major (backwards incompatible) changes 
after the next v0.5 release, I also wanted to finish a few other things first. 
But that todo list only grew, with the known result...

So it looks like it doesn't work really well for me either. So let's try a more 
time based release cycle.

> But even then, it's actually much better to make the "does this
> version support XYZ" depend on something like
>
>      #ifdef XYZ
>
> than on
>
>      #if version_newer_than(5,1,1)
>
> because it makes it *much* easier to both back-port features to stable
> sub-releases (eg think of a situation where you added something to
> 0.5, but then also backported it to 0.4.2, so now that
> "version_newer_than()" thing gets to be a mess), and makes the use
> much more obvious.

In the stable releases, I'm only doing pure bugfixing. No new features get 
backported there, so that shouldn't be a problem.

> It also makes it much easier to _test_ new features - stuff that isn't
> necessarily ready for a release, but that you want testing for.
>
> And there's very much a chicken-and-egg problem: how do you intend to
> make a good release with a solid new feature, if you make it hard for
> users to test that feature?

That's indeed a very good argument.

Anyway, assume I provide feature macros from now on, my main concerns are as 
follows:

I consider the master branch as work-in-progress. This is where all new features 
get introduced. But since it's a new feature, it's not necessary right from the 
start. So it might take a few iterations to get the api right. With a feature 
detection macro, you'll be able to detect the presence of the feature itself, 
but not each intermediate variant. That means an application may no longer work 
correctly or even build against a certain range of commits on master. Do you 
consider that a problem? (Of course I'll try to avoid those kind of problems, 
but for me the point of a development branch is being able to change things 
without having to worry too much about possibly breaking stuff.)

A feature macro only works at build time, and for C/C++ applications. But there 
are several non C/C++ applications (written in .NET, python, maybe even some 
java ones) out there that can't use macros at all. Their only option is runtime 
version detection using the dc_version_check() function. Since those 
applications are certainly not second class citizens, the version based 
detection will always remain the reference. But in addition there will be 
feature detection macros.

Does that sounds a reasonable approach?

> So please use that feature-define model rather than the _completely_
> broken "release numbering test" model. Because really, it *is*
> completely broken.

The release number model is nevertheless used by many (most?) software 
libraries. But let's not argue about that any further :-)

Jef