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? 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.
In my personal opinion - wild versioning should go away. We need to
impose stardards on versions: at least major.minor.build-[etc]. So - any
additive changes increment minir version, any incompatible changes
increment major. Build - for developer/QA test/release iterations. We
can enforce those rules for binary compatibility, but behavioral
compatibility will still be volatile :(
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.
The approach above goes in this direction - it might give some
guarantees. But not too strong - we cannot test behavioral compatibility.
Thanks,
Oleg
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
