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? The dependent project might release a new
3.8.x release that isn't compatible. 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. 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.
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. 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.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
