[ale] Stable, backward compatible APIs

[Jim Kinney]

It _sounds_ good but it's not feasible. For an API to be stable for
years, it must be very simple, very limited and mostly ignored. A
desktop environment fits none of those.

This doesn't work in Mac/Windows land either. Apps that used the
desktop gui are hit-or-miss after an upgrade to a new OS on either of
those. The way they handle this is with long-term support.

Keep in mind that most commercial crap is released when it compiles.
They'll patch later with the upgrades. So hard stuff like API design
for a decade is really not going to happen. In Linux-land, API design
is done by committee, coded up and then a new committee comes in.
Yeah. That works well :-)

On Thu, Aug 30, 2012 at 4:54 PM, JD <jdp at algoloma.com> wrote:
> Thanks for the thoughtful response.
>
> On 08/30/2012 03:58 PM, Lightner, Jeff wrote:
>> Of course this is why RHEL is setup the way it is.   You can put your
>> Enterprise on it and trust that you don't have to do a complete revamp of
>> everything every year or so.   (In fact for RHEL5 Redhat announced earlier
>> this year they were extending its life from 7 years to 10 years even though
>> RHEL6 has been out for over a year.)
>
> I probably wasn't as clear as I could have been.  I wasn't talking about long
> term support for a specific release.  Ubuntu LTS releases have support for 5
> yrs, but that isn't really what we need.  Being stuck on old an old OS release
> to run an old commercial program is the issue.
>
> Rather we are talking about consumer-level desktop releases that supports
> programs over many years. Since I haven't touched anything from RH since 2002, I
> can't talk in those terms - but what end-users need and demand is a stable API
> across Ubuntu 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 .... with new APIs added, but
> old APIs remaining for GUI programs.  Any program that ran on Ubuntu 6.06 should
> be able to run unchanged on Ubuntu 14.04.
>
> Backwards compatibility, while not forcing anyone to hold back their desktop OS
> revision.
>
> Any Gnome2 program should work under Gnome3. Any KDE3 under KDE4. Just look at
> Android v1.6 programs that work under Android 4.1+ and every version in between.
>  A few programs are tied to specific hardware but the vast majority of them are
> not. They are Android compatible.
>
>> On the flip side it means some things on RHEL get a bit long in the tooth.
>> (e.g. BIND 9.3 is the base RedHat uses on RHEL5)  Redhat does backport
>> security and bug fixes from later upstream versions into theirs but still it
>> becomes limited compared to newer things.  But then again for an app like
>> that you can always forego the RHEL provided package and download/build the
>> latest from source.
>
> Programs that do not cost SW-CAP to install don't count.  It is the Adobe
> programs, the gee-wiz-bang new gaming company and Intuit who need this level of
> commitment.  It would help smaller developers too.
>
> Sorry, but until Quickbooks works on a Linux desktop, tens of thousands of small
> accounting companies will not switch.  Saying we don't want those end-users,
> does them and us a disservice.  Linux desktops should be inclusive, not exclusive.
>
> Building from source is not an option for most commercial offerings on a
> desktop.  For example, build Skype from source.
>
> Perhaps the Linux Foundation can lead the effort for a stable API?
>
> I believe that servers are a different animal.  The merits of Linux + GNU with
> BSD/MIT/Apache licenses have all but won this market already.
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo



-- 
--
James P. Kinney III

Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain

http://electjimkinney.org
http://heretothereideas.blogspot.com/