elb at pidgin.im
Fri Apr 9 13:26:47 EDT 2010
Phil Hannent spake unto us the following wisdom:
> Wanted to ask a polite question about your version control if I may.
> Recently there has been talk of 2.7.0 and 3.0.0 having API changes and
> waiting on things for release. However I don't understand why you
> work in that fashion. I can understand when you say that each version
> will be supported for 3 or 5 years. However that traditionally was
> not how Pidgin and Gaim were developed.
It is not, in that the Pidgin project itself does its best to not
spend a lot of time looking back. There are two groups for whom we
try not to make changes without any forethough, howeever. First, we
try not to make life *too* hard for our downstream packagers. We have
a bit of a streak of idealism, on a whole, so we'll throw a wrench
into downstream plans on occasion, but we do try to think of them.
This means that major changes almost invariably involve backports to
previous major releases; look at the 1.5.x/2.x series to see this.
There were distributions which held on to 1.5.x releases for many
months after 2.0.0 was out. We wound up porting quite a few patches
to the 1.5.x series, and this sort of effort is at times a
> In the Gaim days you had the simple 0.xx numbering, when it changed
> you knew something might break. You changed to the current numbering
> system to make it easier for plugin developers to know the level of
> change to the API.
This is the second prong; third-party developers. There are more
third-party users of Pidgin and libpurple now than ever before,
including no less than three entire separate IM clients/libraries
built on libpurple. Major version releases (which throw away existing
API, or change its behavior in a non-backward-compatible way) are
potentially problematic for these users, in that they may require
either a fork in the code base (one fork for each major revision) or
significant alignment effort in the runtime code (#ifdefs,
functionality to patch up differences, etc.).
> But why hold off for several API changes into one big bang release?
> Why not, hypothetically speaking, release 3.0.0 with the new privacy
> API now, and GObjectification in 5 months time with 4.0.0?
We can do this, and we've discussed it before. However, for the above
reasons, and for the simplicity of our own project management, if we
have a number of changes which can be wrapped up together, we feel
it's better to take care of these things all in one go.
It's not that it *can't* be done differently, it's simply that we
think batching is the right way to go.
The laws that forbid the carrying of arms are laws [that have no remedy
for evils]. They disarm only those who are neither inclined nor
determined to commit crimes.
-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 481 bytes
Desc: Digital signature
More information about the Devel