Linked by Thom Holwerda on Wed 29th Aug 2012 22:52 UTC
Permalink for comment 533115
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 06/13/13 14:35 UTC
Linked by Thom Holwerda on 06/11/13 17:07 UTC
Linked by Thom Holwerda on 06/10/13 23:13 UTC
Linked by Thom Holwerda on 06/08/13 14:57 UTC
Linked by Thom Holwerda on 06/07/13 11:40 UTC
Linked by Thom Holwerda on 06/04/13 12:45 UTC
Linked by nfeske on 05/31/13 10:12 UTC
Linked by Thom Holwerda on 05/29/13 16:59 UTC
Linked by Thom Holwerda on 05/24/13 17:26 UTC
Linked by Thom Holwerda on 05/21/13 21:38 UTC
More Features »
Sponsored Links



Member since:
2008-08-19
I would argue that the same needs to be done for applications.
For the most part, that's already the case - for example, an app written to Gtk+ 2.0 back in 2002 will still probably compile and run on Gtk+ 2.24 today. It probably uses parts of that API which have long been deprecated, but it will still work. That's over ten years of stability.
For an actual API break, you have to go to Gtk+ 3.0, where they finally cleaned out all of those old deprecated functions. But even then, it's not a problem, because the 2.0 and 3.0 libraries have been designed to co-exist..