[OTR-dev] otrproxy and packaging

[Greg Troxel]

  - The version numbers for libotr from now on will follow the usual
    convention: major number changes denote non-backwards-compatible API
    changes, minor number changes denote backwards-compatible API changes,
    sub number changes denote implementation changes, but no API changes.

And presumably the shlib number for libotr.so will bump similarly to
the first two version numbers.

  - They'll need to be packaged separately now.  Maybe something like this:

Your proposal is very linux-centric.  But, the real question is:

  For the proposed tarball release strategy, will each of the
  packaging systems be able to do something rational, without having
  to do something they consider icky.

What you listed seems to fit the linux world.

For pkgsrc (NetBSD, but also many other OSes), I would see things
being similar, except no libotr/libotr-dev split - compiling from
source is the dominant paradigm, so that is rare.

So I think it's fine.