Bump version to 2.90dev in preparation for release.

Update some documentation.

4 files changed, 20 insertions, 10 deletions

diff --git a/NEWS b/NEWS
index 12c26fbc..c975a4b2 100644
--- a/NEWS
+++ b/NEWS
@@ -1,4 +1,4 @@
-* Wed Mar 18 2009 Eric S. Raymond <esr@snark.thyrsus.com> - 2.40dev
+* Thu Nov 19 2009 Eric S. Raymond <esr@snark.thyrsus.com> - 2.90dev
   GPSD-NG, the new JSON-based command protocol, is now deployed; as a
   consequence, AIS is now fully supported in both daemon and client.
   Detection of end of a fix-reporting cycle is now reliable;
diff --git a/configure.ac b/configure.ac
index 273bfbdf..8e6e561c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,6 +1,6 @@
 dnl $Id$
 AC_INIT
-AM_INIT_AUTOMAKE(gpsd, 2.40dev)
+AM_INIT_AUTOMAKE(gpsd, 2.90dev)
 dnl AC_PREFIX_PROGRAM(gcc)
 AM_CONFIG_HEADER(gpsd_config.h)
 AC_CONFIG_MACRO_DIR([m4])
diff --git a/www/index.html.in b/www/index.html.in
index d7c331d9..951d99d7 100644
--- a/www/index.html.in
+++ b/www/index.html.in
@@ -64,6 +64,16 @@
 
 <div id="Content">
 
+<h1 id='news'>Urgent news for maintainers of <code>gpsd</code> clients</h1>
+
+<p>We've been warning it was coming for years, and it's here: the
+request/response protocol used by <code>gpsd</code> is about to change
+in ways that will break your application if you're not careful.  The
+old protocol is still supported, but will remain so only for a very
+limited time.  Read <a href="protocol-transition.html">"Moving to
+GPSD-NG: a Guide for Client Developers"</a> to find out why this is
+happening and what you need to do about it.</p>
+
 <h1>About <code>gpsd</code></h1>
 
 <p><code>gpsd</code> is a service daemon that monitors one or more
@@ -126,8 +136,8 @@ the *BSD family.  Presently Linux and OpenBSD are directly supported.
 We'll support proprietary Unixes if it's not too much work (and it
 usually isn't). Apple's OS X is back in our good books, but it is
 criticial that you have all your USB drivers updated. Older drivers
-are buggy and prevent gpsd from being able to read from usb-serial
-devices.</p>
+are buggy and prevent <code>gpsd</code> from being able to read from
+USB-serial devices.</p>
 
 <p>No, we don't support Windows &mdash; get a better operating system.</p>
 
diff --git a/www/protocol-transition.txt b/www/protocol-transition.txt
index 78bb6930..b0bb7b48 100644
--- a/www/protocol-transition.txt
+++ b/www/protocol-transition.txt
@@ -1,6 +1,6 @@
 = Moving to GPSD-NG: a Guide for Client Developers =
 Eric S. Raymond <esr@thyrsus.com>
-v1.0, August 2009
+v1.1, November 2009
 
 == Why a new protocol? ==
 
@@ -15,8 +15,8 @@ RTCM3.
 
 Yes, we could as a desperate expedient have pressed non-alphabetic
 printables into service - but the result would have looked like
-line noise and only delayed the day of reckoning.  Instead, we're
-writing a new protocol that is upward-compatible with the old one 
+line noise and only delayed the day of reckoning.  Instead, we've
+written a new protocol that is upward-compatible with the old one 
 in that you can mix old and new syntax.
 
 The old protocol will continue to be available for some time, but not
@@ -122,8 +122,8 @@ that has made us rethink some of the assumptions behind the old one.
 
 Since we knew we were going to have a forced compatibility break at the
 wire-protocol level anyway, we decided not to do things by halves.  One
-big break - in the application model, struct gpsdata_t, and the
-wire protocol behind it - is better than three or four spread out
+big break -- in the application model, struct gpsdata_t, and the
+wire protocol behind it -- is better than three or four spread out
 over a period of time.  
 
 As a result, the new protocol is not an exact superset of the old one.
@@ -263,7 +263,7 @@ wire protocol, it is extremely unwise to assume that the first
 transmission from the damon after a command is shipped to it will be
 the reponse to command.  If you must send explicit
 commands to the daemon, use gps_send() and handle the response in
-your main event-polling loop - but beware, as using gps_send()
+your main event-polling loop -- but beware, as using gps_send()
 ties your code to the GPSD wire protocol and is not recommended.
 
 The client library's reporting structure, struct gpsdata_t, has a new