On 21-Jun-08, at 11:16 PM, Ralph Goers wrote:
See below
Brett Porter wrote:
Hi Oleg, all,
I haven't dug into any of the code yet, but I've read through the
document you were working on. It seems positive and makes sense. I
did get a bit lost on the meaning of the "Tree Builder" section as
it doesn't seem to describe the current tree or graph technique,
but maybe illustrate the possible combinations?
Anyway, a few things caught my attention...
You mentioned about the inconsistency of whether 3.8.1 means "must
be 3.8.1" vs "I'm using 3.8.1 right now but I'm not really sure
which versions it works with". Pretty much everyone putting POMs
together does the latter, as they are not trained in specifying
ranges, and because projects do not always follow the guidelines on
versioning such that compatibility can be measured. You also
mentioned that some change to the way ranges are specified might be
needed. I'm wondering what thoughts you have on how we specify
dependencies need to be different from today?
This is one of the problems that has bothered me for a while. It
makes no sense for a project to say I'm compatible with 3.8.x. How
in the world could they know that?
In the world where there is some rigour in that the said project
doesn't change the API within a major release they know very well. In
Eclipse a great deal of care is taken to make sure that APIs don't
change within a major release of the platform and ranges in
dependencies are usually specified as ranges that allow the
consumption of new versions within a major release version. We're not
accustom to this here at Apache because there just isn't that level of
rigour yet.
The dependent project might release a new 3.8.x release that isn't
compatible.
Commercial vendors take a lot more care because people complain
wildly, and Eclipse takes a lot more care. It's not rocket science to
use CLIRR, we along with a lot of other open source projects have just
been lazy.
Thus, for any kind of version range to have any meaning, projects
must declare what prior versions they are compatible with using a
declaration that isn't part of the current pom syntax.
I'm not sure it has to be, there generally isn't a very good reason to
break API compatibility in a major release.
Then when a project specifies a dependency on 3.8.1 if there is a
3.8.2 that specifies it is compatible with any prior 3.8.x release
it would be fine to use 3.8.2 in the project with the dependency.
Without such a specification, in my opinion version ranges aren't
particularly useful.
I disagree. There are generally accepted rules about changes in APIs
in major and minor releases. Takes a conscious effort but tooling can
help as well. There's a big set of tooling available in the eclipse
platform to help with this coming in 3.4.
Frankly, even if version ranges worked as above I'd still probably
not use them during a build simply because I want to specify exactly
what is used in the build.
A lot of people probably do too, but that's not what you've been doing
with the POMs you use now I'm willing to bet. Almost everyone with the
mechanism we have now can be subject to exactly what you describe
above without knowing it. Most people don't know the "1.0" in their
POMs doesn't actually mean use "1.0" all the time.
However, it would be great to know that multiple projects have
dependencies on incompatible versions of the same thing. It would
also be great to have reports that indicate which dependencies could
be safely upgraded.
It should be the exception that it changes in a major version.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more
examples
you look at, the more general your framework will be.
-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
