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
