commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: Design guidelines and SemVer
Date Wed, 18 Feb 2015 13:17:30 GMT
2015-02-18 13:22 GMT+01:00 Stian Soiland-Reyes <stain@apache.org>:

> Also, as changing Java package names is a drastic step, you would
> think three times before introducing breaking changes at all. (or if
> you do - do so with a big bang and "fix everything" :) ).
>
> So I think this specialization looks all sensible, specially for
> Apache Commons which are utility libraries that could easily be found
> multiple times in different versions across dependencies.
>
> So it would be good if the Commons versioning guideline linked to the
> (now pretty well known) semantic versioning doc and was aligned with
> it terminology-wise - as practically it's pretty much the same. Shall
> I sketch out a draft?
>

Sounds like a good idea to me. You can change the side directly by editing
it in svn [1]. Publishing the site is explained on our website as well [2].

Regards,
Benedikt

[1] http://svn.apache.org/repos/asf/commons/cms-site/
[2] http://commons.apache.org/site-publish.html


>
> On 18 February 2015 at 06:19, Benedikt Ritter <britter@apache.org> wrote:
> > 2015-02-18 5:09 GMT+01:00 Peter Ansell <ansell.peter@gmail.com>:
> >
> >> 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 think it is important to take into account what kind of project we're
> > talking about. For a framework like spring or hibernate there is no need
> to
> > change package names and maven coords, because you won't have two
> different
> > versions of the jars in your classpath (it simply makes no sense at all).
> > When talking about little libraries like the one developed at commons,
> > things are different. It is likely that you will end up with several
> > conflicting versions in your classpath through transetive dependencies.
> So
> > often you can do nothing about that, because you don't own the code that
> > references an out dated version of, say commons lang. If we don't go all
> > the way and change both, maven coords and the package name, users will
> have
> > a hard time getting their applications to work.
> >
> > Maybe we should elaborate about this in our versioning guide lines...
> >
> > Regards,
> > Benedikt
> >
> >
> >>
> >> 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
> >>
> >>
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating)
> http://orcid.org/0000-0001-9842-9718
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message