On 22-Jun-08, at 12:03 AM, Oleg Gusakov wrote:
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.
Not without some decent integration tests no. But you have a pretty
good chance with good ITs. We catch lots of shit that compiles, but
bombs in our ITs.
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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.
-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
