You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Emmanuel Bourg <eb...@apache.org> on 2013/10/08 10:55:13 UTC
Re: [DISCUSS] API compatibility policy
Le 07/10/2013 20:14, Benedikt Ritter a écrit :
> - loosen API compatibility policy?
This topic alone deserves its own thread I think.
Ensuring binary/source compatibility is very important. This is an area
where Guava is clearly not a good example, they deprecate and remove
stuff frequently. Every time I update the Debian package for Guava I
know this will break reverse dependencies, I have to fix it and convince
the upstream projects to upgrade as well. On the other hand updating a
Commons component is just a breeze.
That being said, I think we are too strict on the compatibility rules.
Some incompatible changes are much less risky than others. For example,
adding a new method in an interface released less than 6 months ago
shouldn't be vetoed, but renaming public methods in a code that has been
in the wild for years shouldn't happen.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by sebb <se...@gmail.com>.
On 8 October 2013 21:11, Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Oct 8, 2013 at 2:11 PM, sebb <se...@gmail.com> wrote:
>> On 8 October 2013 17:36, Gary Gregory <ga...@gmail.com> wrote:
>>> On Oct 8, 2013, at 10:09, James Carman <ja...@carmanconsulting.com> wrote:
>>>
>>>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>>>>
>>>>> That's not the issue. We want to avoid unresolvable incompatibilities in
>>>>> transitive dependencies. Our components are used by many projects, an
>>>>> incompatibility could render impossible the use of two components
>>>>> together, and you are stuck until the components are updated to use the
>>>>> same version of the common dependency.
>>>>>
>>>>> ASM and BouncyCastle are two examples of widely used projects that don't
>>>>> care at all about the compatibilities, and this is causing pain and
>>>>> wasting time to a lot of smart people.
>>>>
>>>> I think you misunderstand my intent. We have left out features before
>>>> (ones that folks blogged about and said they liked) because a user
>>>> could do something stupid with it.
>>>>
>>>> What you're talking about is "jar hell" and we have already addressed
>>>> that with our naming convention for major release bumps (changing
>>>> artifactId and package name). I'm cool with that idea and I think
>>>> it's a pretty good approach. I don't see anyone else doing it, which
>>>> is interesting.
>>>>
>>>
>>> Yep, our approach works. You cannot be kind of binary compatible, it's
>>> all or nothing.
>>
>> Yes and no.
>
> You can't tell me with a straight face that binary compatibility is
> not a strict true/false attribute ;)
>
> While I agree with the overall feel of your message, my experience
> makes be love BC. Even small apps that end up with layers of 3rd party
> jar deps leads you immediately to jar hell if there is no binary
> compatibility within packages. This is why our change of package name
> (and maven coords) guideline works so well.
>
> Sure, some corner method is a tucked away class may never be used
> outside the jar, but, if it's public, don't break it. You just do not
> know what call sites are going to do.
Each incompatibility needs to be decided on its merits.
For example, if a class or method is clearly documented as internal or
experimental, then anyone that relies on it should not be surprised if
problems occur. Just the same as if one uses a class from a sun.*
package.
There are other examples where the field or code may be part of the
public API, but nevertheless making use of it is clearly wrong.
For example, writing to an entry in a protected final array which
contains constants. (The array should have been private with an
accessor).
I'm sure there have been other cases.
> I have no problem bumping major versions., package names, and Maven
> coords in order to keep a project evolving at 21st century speeds.
I prefer that to jar hell and/or stagnation, however the downside is
additional work downstream.
The choice is not always black/white.
> This is probably why I am OK with a stricter BC definition.
>
> Gary
>
>
>>
>> Yes, one can say unambiguously that a particular change is - or is not
>> - binary compatible according to the Java compatibility rules.
>>
>> But it may still be OK to break binary compatibility without package
>> renames if the likelihood of it affecting end users is extremely low.
>>
>> I think the way to approach binary incompatibility is as follows:
>> - check whether it's really necessary to break compatibility;
>> sometimes it happens by accident and can be fixed
>> - if the break really is necessary, evaluate how likely it is to
>> affect 3rd party code.
>>
>> Depending on the severity of the break, it may be necessary to change
>> package name/Maven coordinates, or it may just require a warning in
>> the release notes.
>>
>> It's not always easy to get this right, which is where it's useful to
>> have a community of experienced developers.
>>
>>> I do like the idea of internal package names like
>>> Eclipse does. This would not stop me from hacking my way in there but
>>> at least I should not be surprised if a minor version breaks internal
>>> binary compat.
>>
>> +1
>>
>> But it's not always obvious initially which classes are which.
>>
>> [Also of course one should start by making everything private
>> (especially mutable fields) and only increasing visibility as needed.]
>>
>>> Gary
>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Oct 8, 2013 at 2:11 PM, sebb <se...@gmail.com> wrote:
> On 8 October 2013 17:36, Gary Gregory <ga...@gmail.com> wrote:
>> On Oct 8, 2013, at 10:09, James Carman <ja...@carmanconsulting.com> wrote:
>>
>>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>>>
>>>> That's not the issue. We want to avoid unresolvable incompatibilities in
>>>> transitive dependencies. Our components are used by many projects, an
>>>> incompatibility could render impossible the use of two components
>>>> together, and you are stuck until the components are updated to use the
>>>> same version of the common dependency.
>>>>
>>>> ASM and BouncyCastle are two examples of widely used projects that don't
>>>> care at all about the compatibilities, and this is causing pain and
>>>> wasting time to a lot of smart people.
>>>
>>> I think you misunderstand my intent. We have left out features before
>>> (ones that folks blogged about and said they liked) because a user
>>> could do something stupid with it.
>>>
>>> What you're talking about is "jar hell" and we have already addressed
>>> that with our naming convention for major release bumps (changing
>>> artifactId and package name). I'm cool with that idea and I think
>>> it's a pretty good approach. I don't see anyone else doing it, which
>>> is interesting.
>>>
>>
>> Yep, our approach works. You cannot be kind of binary compatible, it's
>> all or nothing.
>
> Yes and no.
You can't tell me with a straight face that binary compatibility is
not a strict true/false attribute ;)
While I agree with the overall feel of your message, my experience
makes be love BC. Even small apps that end up with layers of 3rd party
jar deps leads you immediately to jar hell if there is no binary
compatibility within packages. This is why our change of package name
(and maven coords) guideline works so well.
Sure, some corner method is a tucked away class may never be used
outside the jar, but, if it's public, don't break it. You just do not
know what call sites are going to do.
I have no problem bumping major versions., package names, and Maven
coords in order to keep a project evolving at 21st century speeds.
This is probably why I am OK with a stricter BC definition.
Gary
>
> Yes, one can say unambiguously that a particular change is - or is not
> - binary compatible according to the Java compatibility rules.
>
> But it may still be OK to break binary compatibility without package
> renames if the likelihood of it affecting end users is extremely low.
>
> I think the way to approach binary incompatibility is as follows:
> - check whether it's really necessary to break compatibility;
> sometimes it happens by accident and can be fixed
> - if the break really is necessary, evaluate how likely it is to
> affect 3rd party code.
>
> Depending on the severity of the break, it may be necessary to change
> package name/Maven coordinates, or it may just require a warning in
> the release notes.
>
> It's not always easy to get this right, which is where it's useful to
> have a community of experienced developers.
>
>> I do like the idea of internal package names like
>> Eclipse does. This would not stop me from hacking my way in there but
>> at least I should not be surprised if a minor version breaks internal
>> binary compat.
>
> +1
>
> But it's not always obvious initially which classes are which.
>
> [Also of course one should start by making everything private
> (especially mutable fields) and only increasing visibility as needed.]
>
>> Gary
>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by sebb <se...@gmail.com>.
On 8 October 2013 17:36, Gary Gregory <ga...@gmail.com> wrote:
> On Oct 8, 2013, at 10:09, James Carman <ja...@carmanconsulting.com> wrote:
>
>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>>
>>> That's not the issue. We want to avoid unresolvable incompatibilities in
>>> transitive dependencies. Our components are used by many projects, an
>>> incompatibility could render impossible the use of two components
>>> together, and you are stuck until the components are updated to use the
>>> same version of the common dependency.
>>>
>>> ASM and BouncyCastle are two examples of widely used projects that don't
>>> care at all about the compatibilities, and this is causing pain and
>>> wasting time to a lot of smart people.
>>
>> I think you misunderstand my intent. We have left out features before
>> (ones that folks blogged about and said they liked) because a user
>> could do something stupid with it.
>>
>> What you're talking about is "jar hell" and we have already addressed
>> that with our naming convention for major release bumps (changing
>> artifactId and package name). I'm cool with that idea and I think
>> it's a pretty good approach. I don't see anyone else doing it, which
>> is interesting.
>>
>
> Yep, our approach works. You cannot be kind of binary compatible, it's
> all or nothing.
Yes and no.
Yes, one can say unambiguously that a particular change is - or is not
- binary compatible according to the Java compatibility rules.
But it may still be OK to break binary compatibility without package
renames if the likelihood of it affecting end users is extremely low.
I think the way to approach binary incompatibility is as follows:
- check whether it's really necessary to break compatibility;
sometimes it happens by accident and can be fixed
- if the break really is necessary, evaluate how likely it is to
affect 3rd party code.
Depending on the severity of the break, it may be necessary to change
package name/Maven coordinates, or it may just require a warning in
the release notes.
It's not always easy to get this right, which is where it's useful to
have a community of experienced developers.
> I do like the idea of internal package names like
> Eclipse does. This would not stop me from hacking my way in there but
> at least I should not be surprised if a minor version breaks internal
> binary compat.
+1
But it's not always obvious initially which classes are which.
[Also of course one should start by making everything private
(especially mutable fields) and only increasing visibility as needed.]
> Gary
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Gary Gregory <ga...@gmail.com>.
On Oct 8, 2013, at 10:09, James Carman <ja...@carmanconsulting.com> wrote:
> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>
>> That's not the issue. We want to avoid unresolvable incompatibilities in
>> transitive dependencies. Our components are used by many projects, an
>> incompatibility could render impossible the use of two components
>> together, and you are stuck until the components are updated to use the
>> same version of the common dependency.
>>
>> ASM and BouncyCastle are two examples of widely used projects that don't
>> care at all about the compatibilities, and this is causing pain and
>> wasting time to a lot of smart people.
>
> I think you misunderstand my intent. We have left out features before
> (ones that folks blogged about and said they liked) because a user
> could do something stupid with it.
>
> What you're talking about is "jar hell" and we have already addressed
> that with our naming convention for major release bumps (changing
> artifactId and package name). I'm cool with that idea and I think
> it's a pretty good approach. I don't see anyone else doing it, which
> is interesting.
>
Yep, our approach works. You cannot be kind of binary compatible, it's
all or nothing. I do like the idea of internal package names like
Eclipse does. This would not stop me from hacking my way in there but
at least I should not be surprised if a minor version breaks internal
binary compat.
Gary
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Gary Gregory <ga...@gmail.com>.
The only relaxing I could see is for code in internal packages.
Gary
On Oct 8, 2013, at 12:28, James Carman <ja...@carmanconsulting.com> wrote:
> Okay, so what I'm hearing is that we want to relax our "no API breaks
> within a major release" policy. Also, it sounds like we need to come
> up with the naming convention where we can rope off parts of our API
> as implementation details and they're not to be relied upon by outside
> parties (they may do so at their own peril).
>
> On Tue, Oct 8, 2013 at 12:22 PM, Phil Steitz <ph...@gmail.com> wrote:
>>
>>
>>> On Oct 8, 2013, at 7:08 AM, James Carman <ja...@carmanconsulting.com> wrote:
>>>
>>>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>>>
>>>> That's not the issue. We want to avoid unresolvable incompatibilities in
>>>> transitive dependencies. Our components are used by many projects, an
>>>> incompatibility could render impossible the use of two components
>>>> together, and you are stuck until the components are updated to use the
>>>> same version of the common dependency.
>>>>
>>>> ASM and BouncyCastle are two examples of widely used projects that don't
>>>> care at all about the compatibilities, and this is causing pain and
>>>> wasting time to a lot of smart people.
>>>
>>> I think you misunderstand my intent. We have left out features before
>>> (ones that folks blogged about and said they liked) because a user
>>> could do something stupid with it.
>>>
>>> What you're talking about is "jar hell" and we have already addressed
>>> that with our naming convention for major release bumps (changing
>>> artifactId and package name). I'm cool with that idea and I think
>>> it's a pretty good approach. I don't see anyone else doing it, which
>>> is interesting.
>> I agree that the policy we have now to change package names is reasonable, but it has two drawbacks, one for us and one for users. For us, it forces us to branch and cut a new major release each time we want/need to release something with a compat break. For users, it forces them to redo all of their imports and swallow whatever other refactoring we have thrown in to the major release. I think it makes sense to relax a bit and allow
>>
>> 0) some kind of annotation or naming scheme that allows us to mark classes as "internal"
>> 1) a way to judge some compat breaks even outside the stuff in 0) as "minor" and allow them between major releases.
>>
>> In theory Gump and downstream packaging tools could be used to verify 1), as well as lots of notification / time for comment. I am not sure fixed rules could be defined for it though. We have actually done it a couple of times in [math] and never had anyone scream (though there have been some complaints about API stability in general - which would somewhat ironically likely be improved if we allowed ourselves a little leeway in 0) and 1))
>>
>> Phil
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
Okay, so what I'm hearing is that we want to relax our "no API breaks
within a major release" policy. Also, it sounds like we need to come
up with the naming convention where we can rope off parts of our API
as implementation details and they're not to be relied upon by outside
parties (they may do so at their own peril).
On Tue, Oct 8, 2013 at 12:22 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>
>> On Oct 8, 2013, at 7:08 AM, James Carman <ja...@carmanconsulting.com> wrote:
>>
>>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>>
>>> That's not the issue. We want to avoid unresolvable incompatibilities in
>>> transitive dependencies. Our components are used by many projects, an
>>> incompatibility could render impossible the use of two components
>>> together, and you are stuck until the components are updated to use the
>>> same version of the common dependency.
>>>
>>> ASM and BouncyCastle are two examples of widely used projects that don't
>>> care at all about the compatibilities, and this is causing pain and
>>> wasting time to a lot of smart people.
>>
>> I think you misunderstand my intent. We have left out features before
>> (ones that folks blogged about and said they liked) because a user
>> could do something stupid with it.
>>
>> What you're talking about is "jar hell" and we have already addressed
>> that with our naming convention for major release bumps (changing
>> artifactId and package name). I'm cool with that idea and I think
>> it's a pretty good approach. I don't see anyone else doing it, which
>> is interesting.
>>
> I agree that the policy we have now to change package names is reasonable, but it has two drawbacks, one for us and one for users. For us, it forces us to branch and cut a new major release each time we want/need to release something with a compat break. For users, it forces them to redo all of their imports and swallow whatever other refactoring we have thrown in to the major release. I think it makes sense to relax a bit and allow
>
> 0) some kind of annotation or naming scheme that allows us to mark classes as "internal"
> 1) a way to judge some compat breaks even outside the stuff in 0) as "minor" and allow them between major releases.
>
> In theory Gump and downstream packaging tools could be used to verify 1), as well as lots of notification / time for comment. I am not sure fixed rules could be defined for it though. We have actually done it a couple of times in [math] and never had anyone scream (though there have been some complaints about API stability in general - which would somewhat ironically likely be improved if we allowed ourselves a little leeway in 0) and 1))
>
> Phil
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Phil Steitz <ph...@gmail.com>.
> On Oct 8, 2013, at 7:08 AM, James Carman <ja...@carmanconsulting.com> wrote:
>
>> On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>>
>> That's not the issue. We want to avoid unresolvable incompatibilities in
>> transitive dependencies. Our components are used by many projects, an
>> incompatibility could render impossible the use of two components
>> together, and you are stuck until the components are updated to use the
>> same version of the common dependency.
>>
>> ASM and BouncyCastle are two examples of widely used projects that don't
>> care at all about the compatibilities, and this is causing pain and
>> wasting time to a lot of smart people.
>
> I think you misunderstand my intent. We have left out features before
> (ones that folks blogged about and said they liked) because a user
> could do something stupid with it.
>
> What you're talking about is "jar hell" and we have already addressed
> that with our naming convention for major release bumps (changing
> artifactId and package name). I'm cool with that idea and I think
> it's a pretty good approach. I don't see anyone else doing it, which
> is interesting.
>
I agree that the policy we have now to change package names is reasonable, but it has two drawbacks, one for us and one for users. For us, it forces us to branch and cut a new major release each time we want/need to release something with a compat break. For users, it forces them to redo all of their imports and swallow whatever other refactoring we have thrown in to the major release. I think it makes sense to relax a bit and allow
0) some kind of annotation or naming scheme that allows us to mark classes as "internal"
1) a way to judge some compat breaks even outside the stuff in 0) as "minor" and allow them between major releases.
In theory Gump and downstream packaging tools could be used to verify 1), as well as lots of notification / time for comment. I am not sure fixed rules could be defined for it though. We have actually done it a couple of times in [math] and never had anyone scream (though there have been some complaints about API stability in general - which would somewhat ironically likely be improved if we allowed ourselves a little leeway in 0) and 1))
Phil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
On Tue, Oct 8, 2013 at 10:04 AM, Emmanuel Bourg <eb...@apache.org> wrote:
>
> That's not the issue. We want to avoid unresolvable incompatibilities in
> transitive dependencies. Our components are used by many projects, an
> incompatibility could render impossible the use of two components
> together, and you are stuck until the components are updated to use the
> same version of the common dependency.
>
> ASM and BouncyCastle are two examples of widely used projects that don't
> care at all about the compatibilities, and this is causing pain and
> wasting time to a lot of smart people.
>
I think you misunderstand my intent. We have left out features before
(ones that folks blogged about and said they liked) because a user
could do something stupid with it.
What you're talking about is "jar hell" and we have already addressed
that with our naming convention for major release bumps (changing
artifactId and package name). I'm cool with that idea and I think
it's a pretty good approach. I don't see anyone else doing it, which
is interesting.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 08/10/2013 15:46, James Carman a écrit :
> Another concept I'd like to bring up is the fascination we seem to
> have with protecting the users from being blithering idiots.
That's not the issue. We want to avoid unresolvable incompatibilities in
transitive dependencies. Our components are used by many projects, an
incompatibility could render impossible the use of two components
together, and you are stuck until the components are updated to use the
same version of the common dependency.
ASM and BouncyCastle are two examples of widely used projects that don't
care at all about the compatibilities, and this is causing pain and
wasting time to a lot of smart people.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
Another concept I'd like to bring up is the fascination we seem to
have with protecting the users from being blithering idiots. We
cannot protect them from themselves completely. At some point, we
have to give them the benefit of the doubt that they're not complete
morons. If they do indeed do something as stupid as relying upon type
inference in a case where it's clearly not applicable, then so be it.
They'll get a ClassCastException and figure it out in short order.
On Tue, Oct 8, 2013 at 4:55 AM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>
>> - loosen API compatibility policy?
>
> This topic alone deserves its own thread I think.
>
> Ensuring binary/source compatibility is very important. This is an area
> where Guava is clearly not a good example, they deprecate and remove
> stuff frequently. Every time I update the Debian package for Guava I
> know this will break reverse dependencies, I have to fix it and convince
> the upstream projects to upgrade as well. On the other hand updating a
> Commons component is just a breeze.
>
> That being said, I think we are too strict on the compatibility rules.
> Some incompatible changes are much less risky than others. For example,
> adding a new method in an interface released less than 6 months ago
> shouldn't be vetoed, but renaming public methods in a code that has been
> in the wild for years shouldn't happen.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
That's kind of a mellow song from DMX. He's not yelling as much as usual.
On Tue, Oct 8, 2013 at 8:53 AM, Torsten Curdt <tc...@vafer.org> wrote:
> http://www.youtube.com/watch?v=MqitYkILvnQ&feature=player_detailpage#t=63
>
> Gary, really no offense - but I just could not resist :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Torsten Curdt <tc...@vafer.org>.
http://www.youtube.com/watch?v=MqitYkILvnQ&feature=player_detailpage#t=63
Gary, really no offense - but I just could not resist :)
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
The goal is to level set, so that we don't run into this stuff.
On Tue, Oct 8, 2013 at 9:27 AM, Phil Steitz <ph...@gmail.com> wrote:
>
>
>> On Oct 8, 2013, at 5:52 AM, James Carman <ja...@carmanconsulting.com> wrote:
>>
>> However, code modifications can be vetoed and nobody can overrule the veto.
>>
> Honestly, I have not seen that much, other Sw What we need IMO is less talk and more code. Nobody has "blocked" or "vetoed" any new work on major release versions. What has been lacking is critical mass to really collaborate on the new stuff and fix bugs in the stuff that has been released. There are infinitely many natural numbers to work with. Just change package name, start a branch and go. We should all realize of course that if our APIs are too unstable and we don't back port bug fixes because all we want to do is "innovate" people won't really use our stuff.
>
>>> On Tue, Oct 8, 2013 at 8:49 AM, Gary Gregory <ga...@gmail.com> wrote:
>>> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <ja...@carmanconsulting.com>wrote:
>>>
>>>> Yes, we know we're allowed to do that, but folks seem to fight against
>>>> moving forward.
>>>
>>> All you need is a [VOTE] and be done with it.
>>>
>>> Gary
>>>
>>>
>>>>
>>>> On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>> You can break BC all you want when you do it in a NEW package. For
>>>>> example lang3.
>>>>>
>>>>> Gary
>>>>>
>>>>>> On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
>>>>>>
>>>>>> Cannot remember which component from the top of my head - but it was
>>>>>> related to package name changes.
>>>>>>
>>>>>> My style of thinking: x.y.z
>>>>>>
>>>>>> x - no compatibility
>>>>>> y - source compatibility
>>>>>> z - binary compatibility
>>>>>>
>>>>>> is simple and makes sense.
>>>>>>
>>>>>> It's OK to put some burden on the users when upgrading - as long as the
>>>>>> expectations are set correctly.
>>>>>> But I am pretty sure we discussed that before and some people did not
>>>> agree.
>>>>>>
>>>>>> cheers,
>>>>>> Torsten
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org>
>>>> wrote:
>>>>>>
>>>>>>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>>>>>>
>>>>>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>>>>>
>>>>>>>>> - loosen API compatibility policy?
>>>>>>>
>>>>>>>> This topic alone deserves its own thread I think.
>>>>>>>
>>>>>>>> Ensuring binary/source compatibility is very important.
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> I guess I've done too much ruby with "every bundle update runs the risk
>>>>>>> of breaking everything" lately. I really value the stability commons
>>>>>>> provides.
>>>>>>>
>>>>>>> That being said, I'm sure there are cases where our policy seems
>>>>>>> stricter than it needs to be - even though I haven't seen a really
>>>>>>> difficult case in the one component I contribute to.
>>>>>>>
>>>>>>> Stefan
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Stefan Bodewig <bo...@apache.org>.
+1
Stefan
On 2013-10-08, James Carman wrote:
> Agreed. I think we should come up with a naming convention. The OSGi
> community (the maven bundle plugin) has adopted the notion that any
> package named "impl" or "internal" will not be exported. Perhaps we
> set up that expectation to our users, too. If it's in a package named
> as such, then it can change. Use at your own risk!
> On Tue, Oct 8, 2013 at 9:35 AM, Phil Steitz <ph...@gmail.com> wrote:
>> Sorry, got away from me before I finished. By "other Sw" I meant "other than when someone wants to slip in a comparability break outside a major release." I agree with Luc that we should allow ourselves to designate parts of the API as "internal" so subject to change between major releases. For [math] at least that would be a big help.
>> Sorry for the fat-fingering (again)
>>> On Oct 8, 2013, at 6:27 AM, Phil Steitz <ph...@gmail.com> wrote:
>>>> On Oct 8, 2013, at 5:52 AM, James Carman <ja...@carmanconsulting.com> wrote:
>>>> However, code modifications can be vetoed and nobody can overrule the veto.
>>> Honestly, I have not seen that much, other Sw What we need IMO is less talk and more code. Nobody has "blocked" or "vetoed" any new work on major release versions. What has been lacking is critical mass to really collaborate on the new stuff and fix bugs in the stuff that has been released. There are infinitely many natural numbers to work with. Just change package name, start a branch and go. We should all realize of course that if our APIs are too unstable and we don't back port bug fixes because all we want to do is "innovate" people won't really use our stuff.
>>>>> On Tue, Oct 8, 2013 at 8:49 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <ja...@carmanconsulting.com>wrote:
>>>>>> Yes, we know we're allowed to do that, but folks seem to fight against
>>>>>> moving forward.
>>>>> All you need is a [VOTE] and be done with it.
>>>>> Gary
>>>>>> On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com>
>>>>>> wrote:
>>>>>>> You can break BC all you want when you do it in a NEW package. For
>>>>>>> example lang3.
>>>>>>> Gary
>>>>>>>> On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
>>>>>>>> Cannot remember which component from the top of my head - but it was
>>>>>>>> related to package name changes.
>>>>>>>> My style of thinking: x.y.z
>>>>>>>> x - no compatibility
>>>>>>>> y - source compatibility
>>>>>>>> z - binary compatibility
>>>>>>>> is simple and makes sense.
>>>>>>>> It's OK to put some burden on the users when upgrading - as long as the
>>>>>>>> expectations are set correctly.
>>>>>>>> But I am pretty sure we discussed that before and some people did not
>>>>>> agree.
>>>>>>>> cheers,
>>>>>>>> Torsten
>>>>>>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org>
>>>>>> wrote:
>>>>>>>>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>>>>>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>>>>>>>>> - loosen API compatibility policy?
>>>>>>>>>> This topic alone deserves its own thread I think.
>>>>>>>>>> Ensuring binary/source compatibility is very important.
>>>>>>>>>> 1
>>>>>>>>> I guess I've done too much ruby with "every bundle update runs the risk
>>>>>>>>> of breaking everything" lately. I really value the stability commons
>>>>>>>>> provides.
>>>>>>>>> That being said, I'm sure there are cases where our policy seems
>>>>>>>>> stricter than it needs to be - even though I haven't seen a really
>>>>>>>>> difficult case in the one component I contribute to.
>>>>>>>>> Stefan
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
Agreed. I think we should come up with a naming convention. The OSGi
community (the maven bundle plugin) has adopted the notion that any
package named "impl" or "internal" will not be exported. Perhaps we
set up that expectation to our users, too. If it's in a package named
as such, then it can change. Use at your own risk!
On Tue, Oct 8, 2013 at 9:35 AM, Phil Steitz <ph...@gmail.com> wrote:
> Sorry, got away from me before I finished. By "other Sw" I meant "other than when someone wants to slip in a comparability break outside a major release." I agree with Luc that we should allow ourselves to designate parts of the API as "internal" so subject to change between major releases. For [math] at least that would be a big help.
>
> Sorry for the fat-fingering (again)
>
>> On Oct 8, 2013, at 6:27 AM, Phil Steitz <ph...@gmail.com> wrote:
>>
>>
>>
>>> On Oct 8, 2013, at 5:52 AM, James Carman <ja...@carmanconsulting.com> wrote:
>>>
>>> However, code modifications can be vetoed and nobody can overrule the veto.
>> Honestly, I have not seen that much, other Sw What we need IMO is less talk and more code. Nobody has "blocked" or "vetoed" any new work on major release versions. What has been lacking is critical mass to really collaborate on the new stuff and fix bugs in the stuff that has been released. There are infinitely many natural numbers to work with. Just change package name, start a branch and go. We should all realize of course that if our APIs are too unstable and we don't back port bug fixes because all we want to do is "innovate" people won't really use our stuff.
>>
>>>> On Tue, Oct 8, 2013 at 8:49 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <ja...@carmanconsulting.com>wrote:
>>>>
>>>>> Yes, we know we're allowed to do that, but folks seem to fight against
>>>>> moving forward.
>>>>
>>>> All you need is a [VOTE] and be done with it.
>>>>
>>>> Gary
>>>>
>>>>
>>>>>
>>>>> On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com>
>>>>> wrote:
>>>>>> You can break BC all you want when you do it in a NEW package. For
>>>>>> example lang3.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>>> On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
>>>>>>>
>>>>>>> Cannot remember which component from the top of my head - but it was
>>>>>>> related to package name changes.
>>>>>>>
>>>>>>> My style of thinking: x.y.z
>>>>>>>
>>>>>>> x - no compatibility
>>>>>>> y - source compatibility
>>>>>>> z - binary compatibility
>>>>>>>
>>>>>>> is simple and makes sense.
>>>>>>>
>>>>>>> It's OK to put some burden on the users when upgrading - as long as the
>>>>>>> expectations are set correctly.
>>>>>>> But I am pretty sure we discussed that before and some people did not
>>>>> agree.
>>>>>>>
>>>>>>> cheers,
>>>>>>> Torsten
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org>
>>>>> wrote:
>>>>>>>
>>>>>>>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>>>>>>>
>>>>>>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>>>>>>
>>>>>>>>>> - loosen API compatibility policy?
>>>>>>>>
>>>>>>>>> This topic alone deserves its own thread I think.
>>>>>>>>
>>>>>>>>> Ensuring binary/source compatibility is very important.
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> I guess I've done too much ruby with "every bundle update runs the risk
>>>>>>>> of breaking everything" lately. I really value the stability commons
>>>>>>>> provides.
>>>>>>>>
>>>>>>>> That being said, I'm sure there are cases where our policy seems
>>>>>>>> stricter than it needs to be - even though I haven't seen a really
>>>>>>>> difficult case in the one component I contribute to.
>>>>>>>>
>>>>>>>> Stefan
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Phil Steitz <ph...@gmail.com>.
Sorry, got away from me before I finished. By "other Sw" I meant "other than when someone wants to slip in a comparability break outside a major release." I agree with Luc that we should allow ourselves to designate parts of the API as "internal" so subject to change between major releases. For [math] at least that would be a big help.
Sorry for the fat-fingering (again)
> On Oct 8, 2013, at 6:27 AM, Phil Steitz <ph...@gmail.com> wrote:
>
>
>
>> On Oct 8, 2013, at 5:52 AM, James Carman <ja...@carmanconsulting.com> wrote:
>>
>> However, code modifications can be vetoed and nobody can overrule the veto.
> Honestly, I have not seen that much, other Sw What we need IMO is less talk and more code. Nobody has "blocked" or "vetoed" any new work on major release versions. What has been lacking is critical mass to really collaborate on the new stuff and fix bugs in the stuff that has been released. There are infinitely many natural numbers to work with. Just change package name, start a branch and go. We should all realize of course that if our APIs are too unstable and we don't back port bug fixes because all we want to do is "innovate" people won't really use our stuff.
>
>>> On Tue, Oct 8, 2013 at 8:49 AM, Gary Gregory <ga...@gmail.com> wrote:
>>> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <ja...@carmanconsulting.com>wrote:
>>>
>>>> Yes, we know we're allowed to do that, but folks seem to fight against
>>>> moving forward.
>>>
>>> All you need is a [VOTE] and be done with it.
>>>
>>> Gary
>>>
>>>
>>>>
>>>> On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>> You can break BC all you want when you do it in a NEW package. For
>>>>> example lang3.
>>>>>
>>>>> Gary
>>>>>
>>>>>> On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
>>>>>>
>>>>>> Cannot remember which component from the top of my head - but it was
>>>>>> related to package name changes.
>>>>>>
>>>>>> My style of thinking: x.y.z
>>>>>>
>>>>>> x - no compatibility
>>>>>> y - source compatibility
>>>>>> z - binary compatibility
>>>>>>
>>>>>> is simple and makes sense.
>>>>>>
>>>>>> It's OK to put some burden on the users when upgrading - as long as the
>>>>>> expectations are set correctly.
>>>>>> But I am pretty sure we discussed that before and some people did not
>>>> agree.
>>>>>>
>>>>>> cheers,
>>>>>> Torsten
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org>
>>>> wrote:
>>>>>>
>>>>>>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>>>>>>
>>>>>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>>>>>
>>>>>>>>> - loosen API compatibility policy?
>>>>>>>
>>>>>>>> This topic alone deserves its own thread I think.
>>>>>>>
>>>>>>>> Ensuring binary/source compatibility is very important.
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> I guess I've done too much ruby with "every bundle update runs the risk
>>>>>>> of breaking everything" lately. I really value the stability commons
>>>>>>> provides.
>>>>>>>
>>>>>>> That being said, I'm sure there are cases where our policy seems
>>>>>>> stricter than it needs to be - even though I haven't seen a really
>>>>>>> difficult case in the one component I contribute to.
>>>>>>>
>>>>>>> Stefan
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Phil Steitz <ph...@gmail.com>.
> On Oct 8, 2013, at 5:52 AM, James Carman <ja...@carmanconsulting.com> wrote:
>
> However, code modifications can be vetoed and nobody can overrule the veto.
>
Honestly, I have not seen that much, other Sw What we need IMO is less talk and more code. Nobody has "blocked" or "vetoed" any new work on major release versions. What has been lacking is critical mass to really collaborate on the new stuff and fix bugs in the stuff that has been released. There are infinitely many natural numbers to work with. Just change package name, start a branch and go. We should all realize of course that if our APIs are too unstable and we don't back port bug fixes because all we want to do is "innovate" people won't really use our stuff.
>> On Tue, Oct 8, 2013 at 8:49 AM, Gary Gregory <ga...@gmail.com> wrote:
>> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <ja...@carmanconsulting.com>wrote:
>>
>>> Yes, we know we're allowed to do that, but folks seem to fight against
>>> moving forward.
>>
>> All you need is a [VOTE] and be done with it.
>>
>> Gary
>>
>>
>>>
>>> On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>> You can break BC all you want when you do it in a NEW package. For
>>>> example lang3.
>>>>
>>>> Gary
>>>>
>>>>> On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
>>>>>
>>>>> Cannot remember which component from the top of my head - but it was
>>>>> related to package name changes.
>>>>>
>>>>> My style of thinking: x.y.z
>>>>>
>>>>> x - no compatibility
>>>>> y - source compatibility
>>>>> z - binary compatibility
>>>>>
>>>>> is simple and makes sense.
>>>>>
>>>>> It's OK to put some burden on the users when upgrading - as long as the
>>>>> expectations are set correctly.
>>>>> But I am pretty sure we discussed that before and some people did not
>>> agree.
>>>>>
>>>>> cheers,
>>>>> Torsten
>>>>>
>>>>>
>>>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org>
>>> wrote:
>>>>>
>>>>>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>>>>>
>>>>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>>>>
>>>>>>>> - loosen API compatibility policy?
>>>>>>
>>>>>>> This topic alone deserves its own thread I think.
>>>>>>
>>>>>>> Ensuring binary/source compatibility is very important.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> I guess I've done too much ruby with "every bundle update runs the risk
>>>>>> of breaking everything" lately. I really value the stability commons
>>>>>> provides.
>>>>>>
>>>>>> That being said, I'm sure there are cases where our policy seems
>>>>>> stricter than it needs to be - even though I haven't seen a really
>>>>>> difficult case in the one component I contribute to.
>>>>>>
>>>>>> Stefan
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
However, code modifications can be vetoed and nobody can overrule the veto.
On Tue, Oct 8, 2013 at 8:49 AM, Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Oct 8, 2013 at 8:38 AM, James Carman <ja...@carmanconsulting.com>wrote:
>
>> Yes, we know we're allowed to do that, but folks seem to fight against
>> moving forward.
>>
>
> All you need is a [VOTE] and be done with it.
>
> Gary
>
>
>>
>> On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>> > You can break BC all you want when you do it in a NEW package. For
>> > example lang3.
>> >
>> > Gary
>> >
>> > On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
>> >
>> >> Cannot remember which component from the top of my head - but it was
>> >> related to package name changes.
>> >>
>> >> My style of thinking: x.y.z
>> >>
>> >> x - no compatibility
>> >> y - source compatibility
>> >> z - binary compatibility
>> >>
>> >> is simple and makes sense.
>> >>
>> >> It's OK to put some burden on the users when upgrading - as long as the
>> >> expectations are set correctly.
>> >> But I am pretty sure we discussed that before and some people did not
>> agree.
>> >>
>> >> cheers,
>> >> Torsten
>> >>
>> >>
>> >> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org>
>> wrote:
>> >>
>> >>> On 2013-10-08, Emmanuel Bourg wrote:
>> >>>
>> >>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>> >>>
>> >>>>> - loosen API compatibility policy?
>> >>>
>> >>>> This topic alone deserves its own thread I think.
>> >>>
>> >>>> Ensuring binary/source compatibility is very important.
>> >>>
>> >>> +1
>> >>>
>> >>> I guess I've done too much ruby with "every bundle update runs the risk
>> >>> of breaking everything" lately. I really value the stability commons
>> >>> provides.
>> >>>
>> >>> That being said, I'm sure there are cases where our policy seems
>> >>> stricter than it needs to be - even though I haven't seen a really
>> >>> difficult case in the one component I contribute to.
>> >>>
>> >>> Stefan
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>
>> >>>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Oct 8, 2013 at 8:38 AM, James Carman <ja...@carmanconsulting.com>wrote:
> Yes, we know we're allowed to do that, but folks seem to fight against
> moving forward.
>
All you need is a [VOTE] and be done with it.
Gary
>
> On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> > You can break BC all you want when you do it in a NEW package. For
> > example lang3.
> >
> > Gary
> >
> > On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
> >
> >> Cannot remember which component from the top of my head - but it was
> >> related to package name changes.
> >>
> >> My style of thinking: x.y.z
> >>
> >> x - no compatibility
> >> y - source compatibility
> >> z - binary compatibility
> >>
> >> is simple and makes sense.
> >>
> >> It's OK to put some burden on the users when upgrading - as long as the
> >> expectations are set correctly.
> >> But I am pretty sure we discussed that before and some people did not
> agree.
> >>
> >> cheers,
> >> Torsten
> >>
> >>
> >> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org>
> wrote:
> >>
> >>> On 2013-10-08, Emmanuel Bourg wrote:
> >>>
> >>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
> >>>
> >>>>> - loosen API compatibility policy?
> >>>
> >>>> This topic alone deserves its own thread I think.
> >>>
> >>>> Ensuring binary/source compatibility is very important.
> >>>
> >>> +1
> >>>
> >>> I guess I've done too much ruby with "every bundle update runs the risk
> >>> of breaking everything" lately. I really value the stability commons
> >>> provides.
> >>>
> >>> That being said, I'm sure there are cases where our policy seems
> >>> stricter than it needs to be - even though I haven't seen a really
> >>> difficult case in the one component I contribute to.
> >>>
> >>> Stefan
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
Yes, we know we're allowed to do that, but folks seem to fight against
moving forward.
On Tue, Oct 8, 2013 at 8:35 AM, Gary Gregory <ga...@gmail.com> wrote:
> You can break BC all you want when you do it in a NEW package. For
> example lang3.
>
> Gary
>
> On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
>
>> Cannot remember which component from the top of my head - but it was
>> related to package name changes.
>>
>> My style of thinking: x.y.z
>>
>> x - no compatibility
>> y - source compatibility
>> z - binary compatibility
>>
>> is simple and makes sense.
>>
>> It's OK to put some burden on the users when upgrading - as long as the
>> expectations are set correctly.
>> But I am pretty sure we discussed that before and some people did not agree.
>>
>> cheers,
>> Torsten
>>
>>
>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org> wrote:
>>
>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>
>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>
>>>>> - loosen API compatibility policy?
>>>
>>>> This topic alone deserves its own thread I think.
>>>
>>>> Ensuring binary/source compatibility is very important.
>>>
>>> +1
>>>
>>> I guess I've done too much ruby with "every bundle update runs the risk
>>> of breaking everything" lately. I really value the stability commons
>>> provides.
>>>
>>> That being said, I'm sure there are cases where our policy seems
>>> stricter than it needs to be - even though I haven't seen a really
>>> difficult case in the one component I contribute to.
>>>
>>> Stefan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Gary Gregory <ga...@gmail.com>.
You can break BC all you want when you do it in a NEW package. For
example lang3.
Gary
On Oct 8, 2013, at 6:41, Torsten Curdt <tc...@vafer.org> wrote:
> Cannot remember which component from the top of my head - but it was
> related to package name changes.
>
> My style of thinking: x.y.z
>
> x - no compatibility
> y - source compatibility
> z - binary compatibility
>
> is simple and makes sense.
>
> It's OK to put some burden on the users when upgrading - as long as the
> expectations are set correctly.
> But I am pretty sure we discussed that before and some people did not agree.
>
> cheers,
> Torsten
>
>
> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org> wrote:
>
>> On 2013-10-08, Emmanuel Bourg wrote:
>>
>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>
>>>> - loosen API compatibility policy?
>>
>>> This topic alone deserves its own thread I think.
>>
>>> Ensuring binary/source compatibility is very important.
>>
>> +1
>>
>> I guess I've done too much ruby with "every bundle update runs the risk
>> of breaking everything" lately. I really value the stability commons
>> provides.
>>
>> That being said, I'm sure there are cases where our policy seems
>> stricter than it needs to be - even though I haven't seen a really
>> difficult case in the one component I contribute to.
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Paul Benedict <pb...@apache.org>.
A good resource if you didn't know it existed:
http://commons.apache.org/releases/versioning.html
On Tue, Oct 8, 2013 at 3:54 PM, Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
> <si...@it20one.at> wrote:
> > That's a reasonable style of versioning :)
> >
> > I had many issues with binary compatibilty with a commons-email release
> due to changing the return value from void to a this reference plus some
> moving of constants. You basically end up with either many restrictions or
> creating major releases
>
> Then just create major releases! ;) Why would you not want to provide
> BC? Why add to the jar hell problem? I, the developer, have no control
> over how the API I provide will be used and distributed...
>
> G
>
> >
> > Cheers,
> >
> > Siegfried Goeschl
> >
> >> Am 08.10.2013 um 12:40 schrieb Torsten Curdt <tc...@vafer.org>:
> >>
> >> Cannot remember which component from the top of my head - but it was
> >> related to package name changes.
> >>
> >> My style of thinking: x.y.z
> >>
> >> x - no compatibility
> >> y - source compatibility
> >> z - binary compatibility
> >>
> >> is simple and makes sense.
> >>
> >> It's OK to put some burden on the users when upgrading - as long as the
> >> expectations are set correctly.
> >> But I am pretty sure we discussed that before and some people did not
> agree.
> >>
> >> cheers,
> >> Torsten
> >>
> >>
> >>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org>
> wrote:
> >>>
> >>>> On 2013-10-08, Emmanuel Bourg wrote:
> >>>>
> >>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
> >>>
> >>>>> - loosen API compatibility policy?
> >>>
> >>>> This topic alone deserves its own thread I think.
> >>>
> >>>> Ensuring binary/source compatibility is very important.
> >>>
> >>> +1
> >>>
> >>> I guess I've done too much ruby with "every bundle update runs the risk
> >>> of breaking everything" lately. I really value the stability commons
> >>> provides.
> >>>
> >>> That being said, I'm sure there are cases where our policy seems
> >>> stricter than it needs to be - even though I haven't seen a really
> >>> difficult case in the one component I contribute to.
> >>>
> >>> Stefan
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Cheers,
Paul
Re: [DISCUSS] API compatibility policy
Posted by sebb <se...@gmail.com>.
On 9 October 2013 05:14, Siegfried Goeschl <si...@it20one.at> wrote:
> Hi Gary,
>
> A new major release requires a new package name, site, build and so on - think of commons-lang v1,2,3
Huh?
A major release does not imply an API break, though the reverse is true.
> Cheers,
>
> Siegfried Goeschl
>
>> Am 08.10.2013 um 22:54 schrieb Gary Gregory <ga...@gmail.com>:
>>
>> On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
>> <si...@it20one.at> wrote:
>>> That's a reasonable style of versioning :)
>>>
>>> I had many issues with binary compatibilty with a commons-email release due to changing the return value from void to a this reference plus some moving of constants. You basically end up with either many restrictions or creating major releases
>>
>> Then just create major releases! ;) Why would you not want to provide
>> BC? Why add to the jar hell problem? I, the developer, have no control
>> over how the API I provide will be used and distributed...
>>
>> G
>>
>>>
>>> Cheers,
>>>
>>> Siegfried Goeschl
>>>
>>>> Am 08.10.2013 um 12:40 schrieb Torsten Curdt <tc...@vafer.org>:
>>>>
>>>> Cannot remember which component from the top of my head - but it was
>>>> related to package name changes.
>>>>
>>>> My style of thinking: x.y.z
>>>>
>>>> x - no compatibility
>>>> y - source compatibility
>>>> z - binary compatibility
>>>>
>>>> is simple and makes sense.
>>>>
>>>> It's OK to put some burden on the users when upgrading - as long as the
>>>> expectations are set correctly.
>>>> But I am pretty sure we discussed that before and some people did not agree.
>>>>
>>>> cheers,
>>>> Torsten
>>>>
>>>>
>>>>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org> wrote:
>>>>>>
>>>>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>>>>
>>>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>>>
>>>>>>> - loosen API compatibility policy?
>>>>>
>>>>>> This topic alone deserves its own thread I think.
>>>>>
>>>>>> Ensuring binary/source compatibility is very important.
>>>>>
>>>>> +1
>>>>>
>>>>> I guess I've done too much ruby with "every bundle update runs the risk
>>>>> of breaking everything" lately. I really value the stability commons
>>>>> provides.
>>>>>
>>>>> That being said, I'm sure there are cases where our policy seems
>>>>> stricter than it needs to be - even though I haven't seen a really
>>>>> difficult case in the one component I contribute to.
>>>>>
>>>>> Stefan
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Gary,
A new major release requires a new package name, site, build and so on - think of commons-lang v1,2,3
Cheers,
Siegfried Goeschl
> Am 08.10.2013 um 22:54 schrieb Gary Gregory <ga...@gmail.com>:
>
> On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
> <si...@it20one.at> wrote:
>> That's a reasonable style of versioning :)
>>
>> I had many issues with binary compatibilty with a commons-email release due to changing the return value from void to a this reference plus some moving of constants. You basically end up with either many restrictions or creating major releases
>
> Then just create major releases! ;) Why would you not want to provide
> BC? Why add to the jar hell problem? I, the developer, have no control
> over how the API I provide will be used and distributed...
>
> G
>
>>
>> Cheers,
>>
>> Siegfried Goeschl
>>
>>> Am 08.10.2013 um 12:40 schrieb Torsten Curdt <tc...@vafer.org>:
>>>
>>> Cannot remember which component from the top of my head - but it was
>>> related to package name changes.
>>>
>>> My style of thinking: x.y.z
>>>
>>> x - no compatibility
>>> y - source compatibility
>>> z - binary compatibility
>>>
>>> is simple and makes sense.
>>>
>>> It's OK to put some burden on the users when upgrading - as long as the
>>> expectations are set correctly.
>>> But I am pretty sure we discussed that before and some people did not agree.
>>>
>>> cheers,
>>> Torsten
>>>
>>>
>>>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org> wrote:
>>>>>
>>>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>>>
>>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>>
>>>>>> - loosen API compatibility policy?
>>>>
>>>>> This topic alone deserves its own thread I think.
>>>>
>>>>> Ensuring binary/source compatibility is very important.
>>>>
>>>> +1
>>>>
>>>> I guess I've done too much ruby with "every bundle update runs the risk
>>>> of breaking everything" lately. I really value the stability commons
>>>> provides.
>>>>
>>>> That being said, I'm sure there are cases where our policy seems
>>>> stricter than it needs to be - even though I haven't seen a really
>>>> difficult case in the one component I contribute to.
>>>>
>>>> Stefan
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
<si...@it20one.at> wrote:
> That's a reasonable style of versioning :)
>
> I had many issues with binary compatibilty with a commons-email release due to changing the return value from void to a this reference plus some moving of constants. You basically end up with either many restrictions or creating major releases
Then just create major releases! ;) Why would you not want to provide
BC? Why add to the jar hell problem? I, the developer, have no control
over how the API I provide will be used and distributed...
G
>
> Cheers,
>
> Siegfried Goeschl
>
>> Am 08.10.2013 um 12:40 schrieb Torsten Curdt <tc...@vafer.org>:
>>
>> Cannot remember which component from the top of my head - but it was
>> related to package name changes.
>>
>> My style of thinking: x.y.z
>>
>> x - no compatibility
>> y - source compatibility
>> z - binary compatibility
>>
>> is simple and makes sense.
>>
>> It's OK to put some burden on the users when upgrading - as long as the
>> expectations are set correctly.
>> But I am pretty sure we discussed that before and some people did not agree.
>>
>> cheers,
>> Torsten
>>
>>
>>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org> wrote:
>>>
>>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>>
>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>
>>>>> - loosen API compatibility policy?
>>>
>>>> This topic alone deserves its own thread I think.
>>>
>>>> Ensuring binary/source compatibility is very important.
>>>
>>> +1
>>>
>>> I guess I've done too much ruby with "every bundle update runs the risk
>>> of breaking everything" lately. I really value the stability commons
>>> provides.
>>>
>>> That being said, I'm sure there are cases where our policy seems
>>> stricter than it needs to be - even though I haven't seen a really
>>> difficult case in the one component I contribute to.
>>>
>>> Stefan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Siegfried Goeschl <si...@it20one.at>.
That's a reasonable style of versioning :)
I had many issues with binary compatibilty with a commons-email release due to changing the return value from void to a this reference plus some moving of constants. You basically end up with either many restrictions or creating major releases
Cheers,
Siegfried Goeschl
> Am 08.10.2013 um 12:40 schrieb Torsten Curdt <tc...@vafer.org>:
>
> Cannot remember which component from the top of my head - but it was
> related to package name changes.
>
> My style of thinking: x.y.z
>
> x - no compatibility
> y - source compatibility
> z - binary compatibility
>
> is simple and makes sense.
>
> It's OK to put some burden on the users when upgrading - as long as the
> expectations are set correctly.
> But I am pretty sure we discussed that before and some people did not agree.
>
> cheers,
> Torsten
>
>
>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org> wrote:
>>
>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>
>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>
>>>> - loosen API compatibility policy?
>>
>>> This topic alone deserves its own thread I think.
>>
>>> Ensuring binary/source compatibility is very important.
>>
>> +1
>>
>> I guess I've done too much ruby with "every bundle update runs the risk
>> of breaking everything" lately. I really value the stability commons
>> provides.
>>
>> That being said, I'm sure there are cases where our policy seems
>> stricter than it needs to be - even though I haven't seen a really
>> difficult case in the one component I contribute to.
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by Christian Grobmeier <gr...@gmail.com>.
On 8 Oct 2013, at 12:48, James Carman wrote:
> I think the idea is to change the mindset. There seems to be an
> almost
> militant desire to maintain compatibility. Yes, we have the version
> number
> scheme, but some folks just never want to break compatibility it
> seems.
> This stalls innovation. I don't want to debate every change, so
> setting
> the expectations up-front is a good idea.
+1
> On Tuesday, October 8, 2013, Torsten Curdt wrote:
>> My style of thinking: x.y.z
>>
>> x - no compatibility
>> y - source compatibility
>> z - binary compatibility
>>
>> is simple and makes sense.
+1
I think its more or less semver: semver.org
>> It's OK to put some burden on the users when upgrading - as long as
>> the
>> expectations are set correctly.
>> But I am pretty sure we discussed that before and some people did not
>> agree.
Yes, and thats pretty bad because we cannot innovate any more.
I say: if we have people who want to maintain older version, go for it.
But please
let's stop blocking committers who want to do work a major change which
is not compatible.
If there are only people willing to work on the next major than to
maintain old versions
it is a bit sad, but thats life.
Christian
>>
>> cheers,
>> Torsten
>>
>>
>> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig
>> <bodewig@apache.org<javascript:;>>
>> wrote:
>>
>>> On 2013-10-08, Emmanuel Bourg wrote:
>>>
>>>> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>>>
>>>>> - loosen API compatibility policy?
>>>
>>>> This topic alone deserves its own thread I think.
>>>
>>>> Ensuring binary/source compatibility is very important.
>>>
>>> +1
>>>
>>> I guess I've done too much ruby with "every bundle update runs the
>>> risk
>>> of breaking everything" lately. I really value the stability
>>> commons
>>> provides.
>>>
>>> That being said, I'm sure there are cases where our policy seems
>>> stricter than it needs to be - even though I haven't seen a really
>>> difficult case in the one component I contribute to.
>>>
>>> Stefan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@commons.apache.org<javascript:;>
>>> For additional commands, e-mail:
>>> dev-help@commons.apache.org<javascript:;>
>>>
>>>
>>
---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [DISCUSS] API compatibility policy
Posted by James Carman <ja...@carmanconsulting.com>.
I think the idea is to change the mindset. There seems to be an almost
militant desire to maintain compatibility. Yes, we have the version number
scheme, but some folks just never want to break compatibility it seems.
This stalls innovation. I don't want to debate every change, so setting
the expectations up-front is a good idea.
On Tuesday, October 8, 2013, Torsten Curdt wrote:
> Cannot remember which component from the top of my head - but it was
> related to package name changes.
>
> My style of thinking: x.y.z
>
> x - no compatibility
> y - source compatibility
> z - binary compatibility
>
> is simple and makes sense.
>
> It's OK to put some burden on the users when upgrading - as long as the
> expectations are set correctly.
> But I am pretty sure we discussed that before and some people did not
> agree.
>
> cheers,
> Torsten
>
>
> On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bodewig@apache.org<javascript:;>>
> wrote:
>
> > On 2013-10-08, Emmanuel Bourg wrote:
> >
> > > Le 07/10/2013 20:14, Benedikt Ritter a écrit :
> >
> > >> - loosen API compatibility policy?
> >
> > > This topic alone deserves its own thread I think.
> >
> > > Ensuring binary/source compatibility is very important.
> >
> > +1
> >
> > I guess I've done too much ruby with "every bundle update runs the risk
> > of breaking everything" lately. I really value the stability commons
> > provides.
> >
> > That being said, I'm sure there are cases where our policy seems
> > stricter than it needs to be - even though I haven't seen a really
> > difficult case in the one component I contribute to.
> >
> > Stefan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org<javascript:;>
> > For additional commands, e-mail: dev-help@commons.apache.org<javascript:;>
> >
> >
>
Re: [DISCUSS] API compatibility policy
Posted by Torsten Curdt <tc...@vafer.org>.
Cannot remember which component from the top of my head - but it was
related to package name changes.
My style of thinking: x.y.z
x - no compatibility
y - source compatibility
z - binary compatibility
is simple and makes sense.
It's OK to put some burden on the users when upgrading - as long as the
expectations are set correctly.
But I am pretty sure we discussed that before and some people did not agree.
cheers,
Torsten
On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2013-10-08, Emmanuel Bourg wrote:
>
> > Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>
> >> - loosen API compatibility policy?
>
> > This topic alone deserves its own thread I think.
>
> > Ensuring binary/source compatibility is very important.
>
> +1
>
> I guess I've done too much ruby with "every bundle update runs the risk
> of breaking everything" lately. I really value the stability commons
> provides.
>
> That being said, I'm sure there are cases where our policy seems
> stricter than it needs to be - even though I haven't seen a really
> difficult case in the one component I contribute to.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [DISCUSS] API compatibility policy
Posted by Stefan Bodewig <bo...@apache.org>.
On 2013-10-08, Emmanuel Bourg wrote:
> Le 07/10/2013 20:14, Benedikt Ritter a écrit :
>> - loosen API compatibility policy?
> This topic alone deserves its own thread I think.
> Ensuring binary/source compatibility is very important.
+1
I guess I've done too much ruby with "every bundle update runs the risk
of breaking everything" lately. I really value the stability commons
provides.
That being said, I'm sure there are cases where our policy seems
stricter than it needs to be - even though I haven't seen a really
difficult case in the one component I contribute to.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org