Right, but this would be something completely different from the current
snapshot functionality.
As I said in one of my earlier mails, if you want that functionality you
can open a JIRA request for it (preferably with a patch attached ;) ).
And of course, I retain all my reservations about automatic dependency
upgrade as expressed before. But then, if you want it, it's your
decision. :)
-Lukas
Brian E. Fox wrote:
I think maybe what is being asked for is the ability to get the lastest
non snapshot build? For example if wagon-ftp changes from 1.0 to 1.1, I
want to automatically grab it. Maybe not the best decision, but still a
possible option to allow people to choose. I think that in terms of
versioning modules you have control over, this might be preferrable.
This way a development team could depend on the latest "sanctioned"
version without depending on unstable snapshot builds and without having
to manually update all the poms everytime a new module is published.
-----Original Message-----
From: Lukas Theussl [mailto:[EMAIL PROTECTED]
Sent: Monday, October 31, 2005 1:01 PM
To: Maven Users List
Subject: Re: keyword "SNAPSHOT" in depedency version is ignored
Hi,
What if a released component on remote repository has any bugs?
This just underscores my point, no? Generally, I think upgrading (or
downgrading) a dependency is always something that should be done very
carefully and very consciously, I wouldn't want to have that done
automatically.
Indicating a SNAPSHOT dependency is only useful if you know that a
project is currently under heavy development and you want to stay up to
date with changes on a, say, day-to-day basis (assuming the project
publishes SNAPSHOTs that often). This implies that your project itself
is currently changing frequently, and if something breaks from one day
to the other, you know it might not be due to your own code, but to a
changed dependency. As soon as a stable release gets out, you have to
indicate explicitly (after testing) that you no longer want to use
SNAPSHOTs, but stick to a particular stable version.
If features of a component do not have to be changed to fix bugs, I
think it's useful to replace this bad component on local repository
with bug fixed component on remote repository automatically (after
agreement).
But how would you indicate which component is the good one? A SNAPSHOT
always gets you the _latest_ development version, which is actually very
rarely the most bug-free one! ;)
-Lukas
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]