Thanks Saúl, that sounds like the best approach right now.

Reserved fields in particular sounds like a very very good idea. Any 
forward-looking things you can try to put in place that would allow for 
both API stability and future extensibility would be a good idea. (Within 
reason of course, subject to performance expectations etc.)

-Tony


On Thursday, November 13, 2014 5:05:09 AM UTC-8, Saúl Ibarra Corretgé wrote:
>
> Hi Tony,
>
> I'm sorry we neglected this issue for so long :-(
>
> Unfortunately 1.0.0 is too close to revisit pipes design. Now, we added 
> some reserved fields to several structures to make backwards incompatible 
> ABI changes feasible.
>
> We can try to add some extra APIs on 1.x for helping Julia and have it 
> cleaner on 2. Not sure if it will be possible, but we can try!
>
> Cheers,
> On Nov 13, 2014 5:50 AM, "Tony Kelman" <[email protected] <javascript:>> 
> wrote:
>
>> Just a comment on this. I know you're about to release 1.0.0 soon so I 
>> probably should have spoken up earlier, it might be too late to do anything 
>> now. The oldest open PR in libuv's current repo, 
>> https://github.com/joyent/libuv/pull/451, is keeping JuliaLang on a 
>> private fork, getting linux distros a little bit mad at us, and introducing 
>> some "fun" issues for some adventurous people who are experimenting on 
>> interoperability between Node (or other languages/libraries using libuv) 
>> and Julia. It's been awaiting design feedback towards hopefully eventually 
>> merging some equivalent functionality for almost 2.5 years.
>>
>> If it's doable in a backwards-compatible way then we're fine, ignore me 
>> until after your release. I'm concerned that it might not be. Will Julia 
>> have to wait until libuv 2.0.0 to be able to use unmodified upstream 
>> sources? I'd like to avoid that if possible. Or maybe you fully expect to 
>> have 2.0.0 happen sooner rather than later - though it seems the point of 
>> declaring 1.0.0 is usually that you intend for things to remain stable for 
>> a while, and cut down on the number of incompatible branches you need to 
>> maintain.
>>
>> I believe the most recently rebased version of that patch was in June at 
>> https://github.com/JuliaLang/libuv/compare/eee4776549f4fc1b941506962dfa6e11a9773976...0d5175d7f5ee86c14e325cc5902f196c2b5f4ee4,
>>  
>> we can rebase it again onto master or the v1.x branch if that would help 
>> get the review process going, whenever it would be most convenient.
>>
>> -Tony
>>
>>
>> On Tuesday, September 2, 2014 12:43:34 AM UTC-7, Saúl Ibarra Corretgé 
>> wrote:
>>>
>>> On 09/01/2014 08:27 PM, Iñaki Baz Castillo wrote: 
>>> > 2014-09-01 19:58 GMT+02:00 Bert Belder <[email protected]>: 
>>> >>> Can you really promise that no one 1.X.Y libuv version will change 
>>> >>> anything at API level in a non backwards-compatible manner? really? 
>>> >> 
>>> >> I don't really see why this would be an issue; we can always add 
>>> functions 
>>> >> if we need to expose additional capabilities. 
>>> > 
>>> > Yep. I don't mean adding new features, but keeping the existing ones 
>>> > in 1.0.0 without any API changes. 
>>> > 
>>> > 
>>>
>>> We promised to do so. 
>>>
>>>
>>> -- 
>>> Saúl Ibarra Corretgé 
>>> bettercallsaghul.com 
>>>
>>>
>>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "libuv" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> To post to this group, send email to [email protected] <javascript:>
>> .
>> Visit this group at http://groups.google.com/group/libuv.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"libuv" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.

Reply via email to