In practice it gets more complicated if you are a framework. The safest way is to even change your package name to reflect the API change.
LieGrue, strub ----- Original Message ----- > From: Ron Wheeler <rwhee...@artifact-software.com> > To: users@maven.apache.org > Cc: > Sent: Sunday, September 30, 2012 7:08 PM > Subject: Re: Version ranges not working > > Read what I wrote: > If you are making an artifact that is not upward compatible, you need to > prevent people from thinking that they can just up the version number in > their GAV and they will get a better version with bugs fixed. > You are in fact giving them a new artifact that will not only NOT fix > bugs but will give the victim NoSuchMethods or NullPointers (if scope is > "provided") in code that would work with the previous artifact. > > I don't care if you use the version number as part of the new ArtifactID > or just add the word "nouveau" at the front of the ArtifactID. > Just make sure that you change the G or the A and not just the V. > > Ron > > On 29/09/2012 4:50 PM, Mark Derricutt wrote: >> Wait, >> >> You're suggesting we starting encoding VERSION NUMBERING into the > artefact NAME now? Isn't that just as bad, if not worse than the abuse of > classifiers we already see out there? >> >> We have the exact same issue being discussed here, and also as mentioned by > others use OSGi. One of the key things to think of in all these situations to > also let your artefacts work FOR you. >> >> 1) Separate out APIs from implementations - two artefacts >> 2) Users depend ONLY on API - NEVER implementations - mock those > implementations for testing, or have a third "fake/test" impl. >> 3) Use composite artefacts for grouping common dependencies - a POM only > artefact with dependencies, i.e. a testing pom that deps on testng, > fest-assert > etc. etc. >> 4) Often its only really the packaging/distribution that really needs the > range to be resolved so maybe we should enhance the assembly plugin, or some > other new packaging plugin. >> >> >> >> >> On 29/09/2012, at 8:21 AM, Ron Wheeler > <rwhee...@artifact-software.com> wrote: >> >>> Not acceptable. If a developer is not going to provide upward > compatibility, then they should change the Artifact id to be sure that no one > gets hurt because of the laziness or lack of thoughtfulness or just plain bad > design of the older version. >>> Major versions are not incompatible in most libraries. >>> Hibernate is a good example where the developers realized that version > 3 was completely different from versions. >>> If they wanted to have reasonably method names without the danger of > people getting hurt by trying to run code written to version 2 specs against > version 3, they had to rename the artifacts. >> > > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
