Getting Stuff Done (Re: One critical security flaw...)
Sadrul Habib Chowdhury
imadil at gmail.com
Mon Feb 1 12:10:34 EST 2010
* John Bailey had this to say on [13 Jan 2010, 23:27:17 -0500]:
> (Apologies, all, but this part of the discussion should be moved to the
> development list, which I am now doing.)
> Richard Laager wrote:
> > On Wed, 2010-01-13 at 00:29 -0600, Kevin Stange wrote:
> >> Whatever became of the SoC project to add Keyring support to Pidgin? Is
> >> it a major bump issue or just unfinished?
> > Both. I've been hesitant to put in the time to finish off what's left
> > when I'm not sure we'd actually cut a 3.0.0. People seem really
> > resistant to a major bump for some reason.
> > Richard
> My only reason for being hesitant to rush to 3.0.0 is that I was hoping we could
> get gobjectification done for 3.0.0, but I don't see that happening. In the
> interests of Getting Stuff Done(TM), I propose the following:
> * Finish the ICQ X-Status stuff ASAP for 2.7.0 (string freeze
> for release within 3 days of completed merge).
I personally wouldn't hold up a release because of the X-status stuff,
mostly for two reasons: it affects only one (two?) service/protocol, and
it clearly isn't something a lot of users (and more importantly
developers) want. I would rather suggest that we [try to] include this
in 3.x. That way, it wouldn't be necessary to work around the potential
ABI-breakage (changes in PurpleRequestField) the latest patch causes.
> * As soon as 2.7.0 is out, create a branch such as
> im.pidgin.pidgin.2.7.x (I'm open to better names) from the tag
> of 2.7.0 for future maintenance releases.
> * Once 2.7.x is branched, 2.x.y is API frozen--no new API unless
> absolutely required to fix a security issue.
> * Once 2.7.x is branched, im.pidgin.pidgin is for 3.0.0 development.
> All new features, API additions, etc. should happen only on this
> branch or other branches that will be merged *only* to
I would suggest to make it a 'feature freeze', rather than an
'API freeze'. I would welcome API changes to make 2.x branch cleaner
while the main development continues to happen towards 3.x
This is probably a good time to toy with the idea of decoupling the major
version numbers of libpurple and the UIs (pidgin, finch). I personally
think this is a good idea, but I don't know how much effort would be
needed for this, and if it would be worth the benefits.
More information about the Devel