[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-users] gps_read parameters
From: |
Gary E. Miller |
Subject: |
Re: [gpsd-users] gps_read parameters |
Date: |
Sat, 1 Sep 2018 18:36:45 -0700 |
Yo Charles!
On Sat, 1 Sep 2018 18:47:41 -0600
Charles Curley <address@hidden> wrote:
> > -#define GPSD_API_MAJOR_VERSION 6 /* bump on incompatible
> > changes */ -#define GPSD_API_MINOR_VERSION 1 /* bump on
> > compatible changes */ +#define GPSD_API_MAJOR_VERSION 7 /*
> > bump on incompatible changes */ +#define GPSD_API_MINOR_VERSION
> > 0 /* bump on compatible changes */
>
> I disagree. The 7.0 used to cover only:
>
> * 6.1 - Add navdata_t for more (nmea2000) info.
> * 7.0 - add gps_fix_t.ecef (February 2018)
> */
>
> In July you changed the gps_read API, as noted above.
>
> * 6.1 - Add navdata_t for more (nmea2000) info.
> * 7.0 - add gps_fix_t.ecef (February 2018)
> * changed prototype of gps_read() to add buffer parameters
> */
Yup. No gonna bump the major API more than once between releases.
There have been no releases since the API was bumped.
> That broke 7.0.
No, technically 7.0 is not out since no release has been made since
the bump.
> How is a client program to know at compile time
> whether it is working with a pre-July version or a post-July version
> without a bump in the API version number?
Easy, you get a build error. If you are building programs on git
head, instead of releases, this will happen.
3rd party clients do not need to be able to build with every git
commit. To add that capability would add needless clutter to gpsd
and to clients.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
address@hidden Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can’t measure it, you can’t improve it." - Lord Kelvin
pgpSXDFY8ioUc.pgp
Description: OpenPGP digital signature