RFC: New api for gas changes

[Linus Torvalds]

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

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.

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.

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?

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

                     Linus