[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gpsd-dev
Subject:    Re: [gpsd-dev] =?utf-8?q?=E2=9C=983=2E18_release_soon?=
From:       Fred Wright <fw () fwright ! net>
Date:       2018-09-30 23:07:33
Message-ID: alpine.LRH.2.21.1809301557320.3731 () sh ! sonic ! net
[Download RAW message or body]


On Sat, 29 Sep 2018, Gary E. Miller wrote:
> On Sat, 29 Sep 2018 18:14:39 -0700 (PDT)
> Fred Wright <fw@fwright.net> wrote:
>> On Tue, 25 Sep 2018, Gary E. Miller wrote:
>>
>>> gpsd is looking pretty good right now.  It has been one year since
>>> the last release so I'd like to do a release this week.
>>>
>>> Please test, and send in any last minute concerns.
>>
>> Commit 0711df2b broke xgps running against gpsd 3.17.
>
> Not just that one commit.  Many new features that are not backward
> compatible.  In all the clients.  That is partly why the new version
> checks.  Probably need more version checks, and to bump the JSON
> version.

The client/server protocol operates across machine boundaries, and can't 
assume that the same code version is in use at both ends.  It needs to 
maintain forward and backward compatibility.

JSON is sufficiently flexible that compatibility can be maintained, 
without necessarily resorting to version checks, as long as the code is 
aware of the issues.  For the most part that means ignoring unexpected 
items, and coming up with suitable fallbacks for items that are expected 
but absent.  This should be handled in the client libraries, so that 
individual client programs don't need to worry about it.

> I presume it failed in an ugly way?

Exception backtrace and an unpopulated display.

> A big part of it is that PRNs are a mess and going away.  No way
> around it.

But it needs to be fixed compatibly.  Imagine a new release of a browser 
that only worked with the latest webservers.

Fred Wright

[prev in list] [next in list] [prev in thread] [next in thread]