Plans for 3.0.0

Mark Doliner mark at
Mon Mar 14 01:15:17 EDT 2011

On Sun, Mar 13, 2011 at 9:21 PM, John Bailey <rekkanoryo at> 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 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.  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 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.

> Additionally, I'd like to move to a significantly more modern GTK+ and Glib when
> we do this.  Preferably whatever 2.x minors are current at the time.  (Right now
> that would put us on GLib 2.28.x and GTK+ 2.24.0.)

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


More information about the Devel mailing list