[OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!

[Thibaut VARENE]

On Fri, Aug 31, 2012 at 2:14 PM, Ian Goldberg <ian at cypherpunks.ca> wrote:
> On Fri, Aug 31, 2012 at 12:43:58PM +0200, Thibaut VARENE wrote:
>> >> Yes, I will send patches to the maintainers of these to change their
>> >> Require: libotr to Require: libotr < 4. The libotr3 package will supply
>> >> libotr < 4, while the libotr package will supply libotr >= 4.
>> >
>> > Since they're using the libotr 3 API, shouldn't they require libotr ==
>> > 3?  And the new libotr package will supply libotr == 4, and the new
>> > pidgin-otr package will require libotr == 4?  (As opposed to >= 4?)
>>
>> I think all that is relatively pointless. Ian: libotr2 will no longer
>> be actively maintained/developed when libotr5 is released, right?
>
> If there's a security release needed, I'll consider pushing out a 3.x
> security update for at least a little while, but I haven't set a firm
> timeline policy or anything like that.

OK. That confirms what I was expecting.

>> If so, I plan to move on with the current state of things in Debian:
>> libotr 4.0.0 (source package providing libotr5, -dev and -bin) will
>> *replace* libotr 3.2.1 (source package providing libotr2, -dev and
>> -bin) at which point packages that still require libotr2 will simply
>> break, and their respective maintainers will have to take action.
>
> Isn't that impolite to those maintainers?  Or will you give them a
> heads-up in advance?

The notion of "politeness" in FOSS makes me chuckle ;-)

The heads up they have is 1) (for upstream) your release announcement:
after all, they're writing code that uses your library, so they should
know what they have to do already; and 2) (as far as Debian
maintainers are concerned), the upload of the new version of the
library to 'experimental', which has already happened and is pending
validation.

It appears people are already well aware of the upcoming change too:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685664

Again, we're not breaking libc here. From what I read, I don't think
the new version of libotr will impose a complete rewrite of dependent
software, right? ;-P

>> I don't think libotr has that many dependencies nor is that a critical
>> package that it warrants the maintaining of 2 different versions over
>> the lifetime of major linux and BSD distributions just for the sake of
>> easing dependencies' transitions. At least for Debian, that's how
>> things will be done.
>
> Sounds reasonable.
>
> I plan to build the test releases of 4.0.0 today, including the patch to
> fix the exit() issue, and an extremely minor "remove whitespace at the
> ends of a handful of lines" source cleanup patch.

OK.

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/