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