Backporting to 2.4

[John Ralls]

On Mar 21, 2011, at 9:30 AM, Phil Longstaff wrote:

> Well, this particular checkin (N_ in the root module), or the ones fixing bugs 
> (from Andy Wingo) looked to me like they could be applied to 2.4.  They wouldn't 
> need to since they don't fix user-visible bugs.
> 
> Brings up the question of whether the 2.4.X releases are simply bug fixes or can 
> new smaller bits of functionality and other change be introduced, with 2.6 being 
> reserved for a major change (e.g. Gtk/Gnome 3 support)?  I'd have to look back 
> over the 2.2.X release notices to see what kinds of change were allowed in that 
> series of releases.
> 

Well, some new functionality will have to be backported: In particular, anything that changes storage will have to be readable (and recognizable) by 2.4, even if 2.4 ignores data that it doesn't know what to do with and requires a "save as" to create a 2.4-writable file/db format. Other than the requirement to resave in a new file/db, it should be invisible to the user.

Beyond that, it depends on how long it takes us to get 2.6 out... and that depends on what we decide to put into it, and how we prioritize our work*.  If 2.6 is one year away, then there isn't much motivation to backport new features except where necessary for minimal forward compatibility. If, like 2.4, it's a multi-year effort, then backporting new features is a lot more attractive.

Regards,
John Ralls

* For example, I think that a Gtk migration could be done in less than a year if 2 or 3 people worked nearly exclusively on that. (Rewriting the register is the hard part, I think. I'm led to believe by the Gtk devs that the rest will be pretty mechanical.) Rewiring core and business logic to be fully transactional, and then getting everything that talks to them reconfigured for the new architecture might take 2 years or more with 2 or 3 people.