commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ansell <ansell.pe...@gmail.com>
Subject Re: Design guidelines and SemVer
Date Wed, 18 Feb 2015 04:09:54 GMT
On 18 February 2015 at 12:28, sebb <sebbaz@gmail.com> wrote:
> On 17 February 2015 at 22:56, Peter Ansell <ansell.peter@gmail.com> wrote:
>> On 17 February 2015 at 21:48, sebb <sebbaz@gmail.com> wrote:
>>> On 17 February 2015 at 06:13, Benedikt Ritter <britter@apache.org> wrote:
>>
>> <snip, sounds good>
>>
>>>> and the maven coordinates when we break binary compatibility (= bump up the
>>>> major version number). We do this to avoid jar hell. This way two versions
>>>> of the same commons library can be in the same classpath.
>>>
>>> I hope most other projects with Maven jars do the same, particularly
>>> ones which are libraries.
>>> I know HttpComponents does.
>>
>> I haven't noticed many projects changing their Maven coordinates when
>> bumping the major version number, but it is useful for those reasons,
>> as long as the package names inside also change.
>
> I would hope all projects increase the major version when breaking compat.

Sorry, I should have been clearer. Even in projects that bump the
major version based on a compatibility difference, I haven't noticed
many changing their groupId or artifactId, or changing their Java
package names internally. Obviously they change the version. Changing
package names is just generally viewed as too drastic a step I think
in general, given that Java will ensure typesafety and method
availability when compiling against the new version anyway. And
therefore not needing to change the maven ids as they can't coexist on
the classpath without OSGi/etc. anyway. In the case of OSGi either
method could work given enough effort on the package wrappers part.

I am not trying to say that the system is perfect, but that is what
the general behaviour seems to be, even with people who try very hard
to follow SemVer and similar ideas.

Cheers,

Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message