On 03-06-15 16:54, Linus Torvalds wrote:
On Wed, Jun 3, 2015 at 7:16 AM, Jef Driesen jef@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 XYZthan 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