On 30/09/2012 9:11 PM, Jesse Long wrote:
Regarding documentation, Maven generates a dependencies report, from
the pom.xml, which the user can read.
Regarding changing the artifactId for incompatibility, if you declare
that you use semantic version number, then the user can tell that
there is incompatibility by noticing that the major version number
changed. He must do a full audit of changes when incompatibility is
introduced, regardless of our mechanism of notifying the user that
incompatibility has been introduced.
It is only rare that a version upgrade causes a problem in a well
followed library.
When you depend on dozens of libraries, it is very annoying to find that
someone has screwed up a project by breaking upward compatibility.
You will find the problem at compile time if they change the G or A. If
they only change the V, you may find out in a test if you are lucky but
you may only find out when your clients get stack dumps instead of web
pages.
If you use semantic version numbering, your user will not just assume
that the newest version is compatible. Also, it is unfair on me to
just exclude my transitive dependencies and assume that my code will
work with the newest version of a library I depended on. For all you
know, the newer version of my dependency was released after I the
version of my library you are depending on was released. How was I to
know (and document the fact) that a later version of my dependency
would be incompatible?
You are correct. My only hope is that you have selected vendors or open
source projects that are well managed and are careful about upward
compatibility.
We cannot just assume that newer version are compatible. There are
very real cases where a newer version is not compatible. I must
anticipate that the latest version of my dependencies, as they are
right now, may not be compatible with the latest version in 3 months
time when someone tries to build my project. I want the Maven build to
fail if the user ends up with an incompatible version on the
classpath, and I want to be flexible, not forcing my user to use a
specific version of my dependency if he needs a feature from a newer,
compatible release. I can achieve this by depending on a version
range, defined in accordance to the semantics of the versioning scheme
of the dependency, hopefully http://semver.org/.
You are generally pretty safe with popular projects in assuming upwards
compatibility since they do not want to issue a new release that no
existing user can use without breaking their application.
If you have to tell everyone that they have to rewrite their application
each time you issue a new version of your library, your library will
pretty some lose its user base.
Version ranges are not required, just pick the highest one that you
guarantee to work and leave it at that.
You can not use a higher version in a range than you have tested with.
You should not be putting versions that will only exist in 3 months in
your version ranges so I am not sure that I understand this paragraph.
If the user/developer wants to use a higher version a few years after
you finish development, he/she will have to do some testing or trust
that you have chosen well when you selected the library.
My comments about changing the G or A when you break upward
compatibility is the best way to protect the user community if you can
not figure out how to add new features without breaking old ones.
Most Apache projects are well run and do not break compatibility.
We use a lot of "provided" libraries in my wars since we have a set of
about 60 libraries that we use in about 70 war files so it makes no
sense to have these libraries in every war that we build. We use
libraries from well managed developers who are careful about upward
compatibility so we can be pretty adventurous about moving forward with
the versions. Even major version changes usually preserve upward
compatibility although I confess that I do read the docs a bit more
carefully on a move from 1.15.3 to 2.0 than I would from 1.15.3 to 1.16.1.
Ron
Cheers,
Jesse
On 30/09/2012 19:08, Ron Wheeler wrote:
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
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
