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.
