Release versioning

[Ethan Blanton]

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
not-completely-trivial process.

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

Ethan

-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20100409/269e65f0/attachment.sig>