Proposed changes for Pidgin 2.7.0

[John Bailey]

Kevin Stange wrote:
> Warren Togami wrote:
>> Might we consider calling post-break 3.x?
> 
> I don't think it matters what we call it, really, but the major version
> number change is reserved for API breakage.  We have a lot of that
> planned, but that'd push off the next release with substantial features
> for a potentially long time with a lot of different code to merge.  I
> don't think we want to wait that long.

I agree with Kevin here.  If we do the API-breaking stuff now (we will NOT
release 3.0.0 unless we break API, period), we are then committed to some long
term of 3.x.y releases and forced to make the merge of gobjectification and
other API-breaking Summer of Code projects wait.  We would be committed to this
because I guarantee no one would be happy if we cut 3.0.0 in the next couple
months, then just five or six months down the road cut 4.0.0.  Plugin authors
are going to be extremely unhappy as well, because they'll have to update or
rewrite their plugins a second time in less than a year.  Thus we'd be stuck in
another long major version cycle and be having this same debate in 2-4 years
when the next major version increment comes along.

>> Whatever the break point is called, could we have a critical bug-fix and
>> security only branch of the pre-break?  Declare this branch supported
>> until 2011, and occasionally do point releases for important reasons.
> 
> This is a lot of extra work if our developers have to maintain and test
> this branch for backports since none of us will be using it and the
> changed code may not apply cleanly.  How are you handling pidgin 1.5.1
> in RHEL 3?  Why not handle it the same way here?

Expecting us to support a branch like this for two years *after* we have moved
on is, in my opinion, an unreasonable expectation.  In two years, our code will
be significantly different, and most of us won't even remember the internals of
our 2.6.x code.  As Kevin pointed out above, this also requires us to do more
work to maintain two branches, one of which we ourselves will almost certainly
never use.  We have enough trouble keeping development momentum up as it is.

All that said, if someone outside our development group wants to volunteer to
backport security and bug fixes to some sort of *unofficial* maintenance branch,
I'm sure we can come to a suitable arrangement that makes such a branch easily
accessible for interested packagers without us being expected to maintain it.

> Theoretically someone is backporting security fixes for old Pidgin on
> platforms like Ubuntu and Debian without us.  Lenny is apparently still
> on 2.4.3 and is at "stable" for Debian.

Mandriva recently (June 25) backported some XMPP and MSN security patches from
our 2.5.6 release to their copy of 1.5.0 in their "Corporate 3.0" release.
Presumably they have someone stepping up and doing the backporting as well.

John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20090715/ed9a29df/attachment.sig>