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? On 18 February 2015 at 06:19, Benedikt Ritter <brit...@apache.org> wrote: > 2015-02-18 5:09 GMT+01:00 Peter Ansell <ansell.pe...@gmail.com>: > >> On 18 February 2015 at 12:28, sebb <seb...@gmail.com> wrote: >> > On 17 February 2015 at 22:56, Peter Ansell <ansell.pe...@gmail.com> >> wrote: >> >> On 17 February 2015 at 21:48, sebb <seb...@gmail.com> wrote: >> >>> On 17 February 2015 at 06:13, Benedikt Ritter <brit...@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-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
