RE: [avr-libc-dev] Re: Adding (some) Procyon AVRlib functionality toavr-libc

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of David Brown
> Sent: Sunday, September 20, 2009 1:36 PM
> To: address@hidden
> Subject: [avr-libc-dev] Re: Adding (some) Procyon AVRlib 
> functionality toavr-libc
> 
> 
> That's certainly a risk - there are limitless projects stuck 
> in "alpha 
> test" phase or called "test" for this reason.  Perhaps there 
> should be a 
> rough time limit - anything that remains in "experimental" 
> with a stable 
> API for more than 6 months goes to a vote.  Either people are 
> happy with 
> it and it becomes "stable", or no one is interested in it and it gets 
> chucked out.

There are some difficulties with that plan: who's going to remember to check 
back in 6 months, and who gets to vote?

An alternative below:...

 
> What I want to avoid here is that someone contributes code 
> for a great 
> SPI driver, people start using it, and then someone else 
> points out that 
> some AVRs have more than one SPI bus and the entire API needs to be 
> changed to take that into account.  You end up with a choice 
> of annoying 
> people by changing the API regularly, or annoying people by 
> using an API 
> that doesn't cover the requirements just to avoid changes.  
> Basically, I 
> want to make it perfectly clear to users when they can expect 
> an API to 
> be stable and when it might change.

You certainly bring up good points.

One possibility: When an API is being designed and is being considered for 
inclusion, there must be some work done to make it fit for the existing 
devices, even it's for the 100+ devices that are currently in the AVR family. 
Yes, it's time consuming, but that would ensure that we've at least thought of 
ramifications for all devices, even if they haven't been fully tested out.