Plans for 3.0.0
mark at kingant.net
Mon Mar 14 01:15:17 EDT 2011
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. 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