You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Andrew Phillips <ap...@qrmedia.com> on 2014/06/26 12:02:36 UTC
Binary vs. source-level backwards compatibility?
An interesting question just arose in connection with a PR [1]:
If we say that we want to avoid backwards-incompatible changes in
minor versions [2], do we mean *source* level or *binary* level
compatibility?
ap
[1] https://github.com/jclouds/jclouds/pull/419#issuecomment-47199784
[2] https://wiki.apache.org/jclouds/DeprecationAndBetaPolicy
Re: Binary vs. source-level backwards compatibility?
Posted by Andrew Phillips <ap...@qrmedia.com>.
> https://github.com/jclouds/jclouds/pull/403 (which is still open in
> case anyone has time to merge it).
Merged to master. Looks like we need to do a bit of work to backport
this, though :-( [1]
ap
[1] https://github.com/jclouds/jclouds/pull/403#issuecomment-47428075
Re: Binary vs. source-level backwards compatibility?
Posted by Ignasi Barrera <ig...@gmail.com>.
Agree too in focusing in source code compatibility.
On 30 June 2014 18:27, Everett Toews <ev...@rackspace.com> wrote:
> On Jun 27, 2014, at 8:29 PM, Chris Custine <ch...@gmail.com> wrote:
>
>> Personally I think of this only in the context of source
>> compatibility. This particular issue is kind of a rare case I think,
>> but I think it would be ok to potentially return a value here where
>> there was none before, especially since it was really borked prior to
>> https://github.com/jclouds/jclouds/pull/403 (which is still open in
>> case anyone has time to merge it).
>
> Agreed. I think we can reasonably tackle binary backwards compatibility on a case by case basis. Hopefully it’s a relatively rare thing we have to consider. If it’s coming up often, we should consider making some sort of rule for it.
>
> Everett
>
Re: Binary vs. source-level backwards compatibility?
Posted by Everett Toews <ev...@RACKSPACE.COM>.
On Jun 27, 2014, at 8:29 PM, Chris Custine <ch...@gmail.com> wrote:
> Personally I think of this only in the context of source
> compatibility. This particular issue is kind of a rare case I think,
> but I think it would be ok to potentially return a value here where
> there was none before, especially since it was really borked prior to
> https://github.com/jclouds/jclouds/pull/403 (which is still open in
> case anyone has time to merge it).
Agreed. I think we can reasonably tackle binary backwards compatibility on a case by case basis. Hopefully it’s a relatively rare thing we have to consider. If it’s coming up often, we should consider making some sort of rule for it.
Everett
Re: Binary vs. source-level backwards compatibility?
Posted by Chris Custine <ch...@gmail.com>.
Personally I think of this only in the context of source
compatibility. This particular issue is kind of a rare case I think,
but I think it would be ok to potentially return a value here where
there was none before, especially since it was really borked prior to
https://github.com/jclouds/jclouds/pull/403 (which is still open in
case anyone has time to merge it).
Thanks,
Chris
P.S. I have been trying to send this email for 24 hours and it is
always rejected by Apache mail servers, if several make it at once, I
apologize!
--
Chris Custine
On Thu, Jun 26, 2014 at 4:02 AM, Andrew Phillips <ap...@qrmedia.com> wrote:
> An interesting question just arose in connection with a PR [1]:
>
> If we say that we want to avoid backwards-incompatible changes in minor
> versions [2], do we mean *source* level or *binary* level compatibility?
>
> ap
>
> [1] https://github.com/jclouds/jclouds/pull/419#issuecomment-47199784
> [2] https://wiki.apache.org/jclouds/DeprecationAndBetaPolicy