Getting Stuff Done (Re: One critical security flaw...)

Sadrul Habib Chowdhury imadil at
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
> 	  im.pidgin.pidgin.

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 mailing list