[lcdproc] FW: version 0.4/0.5?
William W. Ferrell
Thu, 22 Mar 2001 16:49:23 -0700
Content-Type: text/plain; charset=us-ascii
--- firstname.lastname@example.org's mailer spewed these beefy chunks ---
> On Mon, 19 Mar 2001, William W. Ferrell wrote:
> > --- email@example.com'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-post1 ?) ?
> > 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.
> 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?
> 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.
> 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.
> 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 :).
> 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
> 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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
Content-Type: text/plain; charset=
To unsubscribe from this list send a blank message to