ETAs for libusbx operability and first release?

[Vitali Lovich]

Just for the record, I'm pretty against any changes to existing APIs in source-incompatible ways.  That does not mean that there won't be an ABI change (i.e. can't do a binary drop-in replacement) or changes to current API in a source-incompatible manner, but there needs to be good justification.  Additionally, libusb doesn't "leak" it's interface, so it's ABI compatibility is actually pretty good version-to-version.

-Vitali

On Jan 30, 2012, at 11:52 AM, Hans de Goede wrote:

> Hi,
> 
> On 01/30/2012 05:46 PM, Segher Boessenkool wrote:
> 
> <snip>
> 
>>> For instance, if you want a hotplug proposal right after the 1.0.9 release,
>> 
>> I'd say hotplug is something for v2.
> 
> I must say that I don't really like the idea of a v2, what I would like
> to see is 1.0.x and master git branches, with everything going to master
> first, with aggressive cherry picking to 1.0.x for fixes, and safe features.
> 
> The occasional more disruptive feature can mature on master and then we
> can do a couple 1.1.x releases from master for testing and then
> jump to 1.2.0 for the first stable release, starting a new 1.2.x branch,
> rinse-repeat.
> 
> I don't think ABI / API breakage is soemthing we should think to lightly
> about. How long has it been since we moved from 0.1 to 1, and how many
> apps are still using 0.1 ? For example libgphoto2, one of our major
> users has only moved to libusb1 very recently!
> 
> I'm not against an ABI breaking v2 if we have too, but I've the feeling
> people are thinking much to lightly about this. If reasonably possible
> we should try to add something like hotplug to the existing v1 libusb.
> 
> Regards,
> 
> Hans
> 
> _______________________________________________
> libusbx mailing list
> libusbx at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libusbx