2015-02-18 13:22 GMT+01:00 Stian Soiland-Reyes <st...@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 <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 > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
