[ale] Stable, backward compatible APIs

Thu Aug 30 19:50:20 EDT 2012

On 08/30/2012 06:58 PM, Tim Watts wrote:
> I'm not so sure the API has to be stable to the point of stagnation in
> order to instill trust.  There are disciplined ways of evolving an API
> and many FOSS communities have done so successfully.  From what I've
> read and seen the problem in the Linux desktop arena has been the
> undisciplined evolution driven by the developers/designers.  Deprecating
> entire subsystems without advance notice because one of the key
> designers thought of a cool new way of doing it over the summer,
> regardless of how entrenched or critical the API may be.  (And no,
> publishing your intent on your blog before the next release doesn't
> count as advance notice.)  I've abandoned a couple small projects
> because of stuff like that.
>
> So in short, I find fault more with the personalities involved than the
> nature of the enterprise.
It sounds like many projects could use a (SA)BDFL to provide continuity.
>
>
> On Thu, 2012-08-30 at 17:33 -0400, Jim Kinney wrote:
>> 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/
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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


-- 
Jay Lozier
jslozier at gmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20120830/77ddc976/attachment.html