Plans for 3.0.0
rekkanoryo at rekkanoryo.org
Mon Mar 14 20:44:18 EDT 2011
On 03/14/2011 01:15 AM, Mark Doliner wrote:
> I like the idea of starting on 3.0.0 and making 2.x.y a "security and
> major bug fixes only" branch. I'm not sure 7 months will be enough.
> Seems like a reasonable target, but I think we should be willing to
> push it back. Two changes I've had in mind for 3.0.0 that could take
> some time are:
> * If a buddy exists in more than one group I think we should only have
> a single PurpleBuddy struct for them.
> * Cleaning up our PurpleStatusType/PurpleStatus/PurpleSavedStatus
> stuff. I'm not sure how exactly... but if feels messy to me and I
> think we can do a better job.
In general, I agree with the idea of pushing back if we need to. But people
have started working on 3.0.0 at least four times in the last three years and
eventually gave up on it. We have so much outstanding stuff that needs to be
merged that I don't think it's at all realistic to try to merge it all for
3.0.0. We'll never finish it at this rate, even if we merge to im.pidgin.pidgin
and force development to happen there. I want to release 3.0.0 before I retire
from my day job ;)
Instead, I think it's wiser to scale back the ambitions, push 3.0.0 out with a
reasonable number of merged projects included, and listen to the crying when we
do this whole discussion again next summer for 4.0.0. If we stick to the
schedule I laid out here for 3.0.0, we *should* be ready to push 4.0.0 in spring
>> A would-be-nice item is the webkit stuff. I'm not sure if this is realistic to
>> fit in the timeframe, but if we can squeeze it in, I'm all for it.
> I feel like webkit is important.
It is, but is it realistic? I'm reasonably certain it's not merge-ready yet.
> I'm ok with requiring more modern stuff, but I don't think we should
> require a high version unless we actually need it. For example, right
> now the highest GLIB_CHECK_VERSION in our source code is 2.18.0 and
> the highest GTK_CHECK_VERSION is 2.18.0.
I know we're not going to rewrite to use it overnight, but more modern GLib
versions provide GIO, which could be useful for a bunch of stuff. Having the
ability to use it, and ideally being GTK+ 3.0.0 ready, even if we don't move to
it, would be nice. And since we're talking a new major version here, we really
don't have any rules to stick to.
> I'm ok with that, too, but I think we should try to avoid it. If the
> effort to provide backward compatibility is minimal then I think we're
> better off keeping things compatible. But I guess we can't really
> make this decision until we have a specific issue.
I'm thinking mainly of the keyring stuff here, where I recall someone mentioning
backward-incompatible changes to accounts.xml.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the Devel