Plans for 3.0.0

Sadrul Habib Chowdhury imadil at gmail.com
Tue Mar 15 14:31:15 EDT 2011


On Mon, Mar 14, 2011 at 1:15 AM, Mark Doliner <mark at kingant.net> wrote:
> On Sun, Mar 13, 2011 at 9:21 PM, John Bailey <rekkanoryo at rekkanoryo.org> wrote:
>> I know I just e-mailed about plans for 2.8.0.  In that e-mail I pointed out that
>> in my ideal world, 2.8.0 will be the last 2.x series for us.  That's because I
>> want to push out 3.0.0 on September 10.  So, here's my plan.
>>
>> I want to start an im.pidgin.pidgin.next.major branch soon (sometime in the next
>> 7 days).  In this branch we'll first kill off all deprecated API in what is now
>> our current codebase.  Once that is complete, we need to get the keyring and
>> logging SoC stuff merged in.  During this time, we should not at all be afraid
>> to change UI concepts or terminologies (such as s/PurpleContact/PurplePerson/
>> and s/PurpleBuddy/PurpleContact/ as has been bandied about a few times).
>
> 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.

I agree with this. Especially since there will be new API, it will
likely need some time to stabilize before it's frozen for 3.x

>  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.

A ridiculous amount of YES on both.

>> I'm also inclined to say that if we break something such that a 3.0.0 .purple
>> can't be used at all by a previous version, we shouldn't lose any sleep over it.
>>  It's a bit nuts, in my opinion, to expect to take the same config directory and
>> use it with more than one major version of the application.
>
> I'm ok with that, too, but I think we should try to avoid it.

I think I'll put a slightly higher value on maintaining backward
compat for the prefs and settings, as I doubt that will incur too much
cost.

Regarding gobjectification, I agree that there are a lot of work left
to be done. But struct hiding I think is a more achievable goal? The
hidden-struct objects can then be gradually gobjectified in the 3.x
series.

Sadrul




More information about the Devel mailing list