[lcdproc] FW: version 0.4/0.5?
William W. Ferrell
wwf@frontierdev.com
Thu, 22 Mar 2001 16:49:23 -0700
--nqkreNcslJAfgyzk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
--- andreb@rd.bbc.co.uk's mailer spewed these beefy chunks ---
> On Mon, 19 Mar 2001, William W. Ferrell wrote:
>=20
> > --- andreb@rd.bbc.co.uk's mailer spewed these beefy chunks ---
> > > On Mon, 19 Mar 2001, David Glaude wrote:
> > >=20
> > > But how do you deal with "backports" from 0.5 to 0.4 after the final =
0.4
> > > (0.4-post1 ?) ?
> >=20
> > I doubt it'll be worth the effort. If we actually pull this off
> > properly, v0.5 will be a much-desired upgrade; I'd like it to *fully*
> > support everything v0.4 did then add some more and still be easier to
> > develop for. v0.4 will hopefully become an unsupported old version.
>=20
> Sure /if/ it's released & stable. But until this point we should support
> 0.4 (bugfixes only ?).
> And all updates/fixes should be shown in the version number.
> But if you do a 0.4 final then here is no space for this (easiest
> fix: label lcdproc0.5 as lcdprocNG and if it's released then assign a
> version to it)
I disagree. LCDproc v0.4-pre10 is the current release, then when we ship
it it'll be called LCDproc v0.4.0, then bugfixes, etc., will increment
the third digit.
> > Can you elaborate a bit on that MtxOrb bug?
>=20
> See Message-Id: <Pine.GSU.4.21.0103221731100.14953-400000@inet14>
Ugh. Either I'm misunderstanding this or I don't have a message with
that ID (I searched message bodies for that in mutt -- is that correct?)
> > Also (if you've already given me this, it's okay to smack me while I get
> > organized again :) can you send along your sourceforge ID so I can add
> > you as a developer, at least to track these todos.
>=20
> Ok: 179561 (note: same name diffrent email addr)
Right. Just added you. Sorry that took so long.=20
> > I'm still sorting out the protocol changes. I started a document about
> > this several months ago I need to dig up -- there were some decent ideas
> > in there.
>=20
> Is here any documention about 0.5 available ?
Not yet. I've misplaced what little I've written, but it's buried on my
notebook somewhere; I'll find it tonight.
> > From what I recall, we decided to go with a human-readable (or at least
> > human-decipherable :) protocol, in the clear (for now, adding support
> > for SSL later) communication except for the initial authentication
> > (shared secret unless somebody seriously feels like implementing
> > public/private key for this monster :).
>=20
> I think SSL is no must because you can use programs like sslwrap/stunnel.
> Plain text proto is fine.
Hadn't thought of that. Thoughts, people? I sorta think SSL would still
be a nice optional feature, but stunnel might just do the trick.
> > able to transmit precise display capabilities to the clients, be more
> > "informative" for inquisitive clients (what are you running on? What
> > version are you? What options are you running with? How many displays
>=20
> Some usefull error codes (like the one in FTP/SMTP/HTTP ...) and=20
> command ids (to track which response belongs to which command) would be
> nice.
K. I'll add that to the list.
--
William W. Ferrell, Senior System Administrator, Global Crossing Ltd.
950 17th St Ste 2200, Denver, CO 80202 1.303.223.0564
Public key available:
gpg --keyserver certserver.pgp.com --recv-key 7478FC7A
We all agree on the necessity of compromise. We just can't agree on
when it's necessary to compromise.
-- Larry Wall
--nqkreNcslJAfgyzk
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjq6j4MACgkQgAeqhXR4/Hoo6QCff3SlbrTgDm8KbG/jUyt4IUxn
00gAoJz24vV5k2q3cUFf8yv8SqXkjbv1
=kodo
-----END PGP SIGNATURE-----
--nqkreNcslJAfgyzk
Content-Type: text/plain; charset=
-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net
--nqkreNcslJAfgyzk--