On 23/01/2008, Michael McCallum <[EMAIL PROTECTED]> wrote:
> On Thu, 24 Jan 2008 03:42:13 Mark Hobson wrote:
> > There is another caveat in that it's all or nothing. Using a profile
> > mechanism will switch all range dependencies into snapshot mode, when
> > typically a developer only wishes to upgrade a couple. How could this
> > be achieved using profiles?
> i can think of two ways off the top of my head
> * install on the specific project
This doesn't work when suitable snapshot repositories are available to
the project, nor when the local repository contains cached snapshots
from other repositories.
> * selective repositories and profiles for different project groups
I move dependencies to their next snapshot when I need to work on
them, so this option would require a profile per dependency which is
unworkable and extremely error prone.
> The real question is what do you hope to achieve by enabling snapshots for a
> particular project or set of projects. Perhaps a change of direction in the
> discussion do you use multiple lines and merging to manage what your
> releases?
In the simplest case, this is how we typically use snapshots to add a
new feature to a previously released project ("A"):
1) A's component ("B") that the new feature will be added to is identified
2) A's dependency on B is upgraded to the next snapshot version, e.g.
1.1 to 1.2-SNAPSHOT
3) Work is carried out on B to add the new feature, installing locally
to receive the changes
4) Work on B is committed to SCM at suitable points for CI to push
changes to any developers working on the same feature
5) When the work is completed, B is released, e.g. 1.2
6) A's dependency on B is upgraded to the released version, e.g. 1.2
7) A is released
Hence the need to be able to switch a single dependency from a release
to the next snapshot is necessary. Is this use case really that
atypical? Version ranges will work in a similar way but with the
following differences:
2) A's dependency on B is upgraded to the next snapshot version, e.g.
[1.0,2.0) to [1.0,2.0-SNAPSHOT)
...
6) A's dependency on B is upgraded to the released version, e.g. [1.0,2.0)
> At the moment I can do continuous integration in two ways
> * head to head (configure continuum deployment #1 to do clean install)
> * latest relevant release to latest relevant release - using version ranges
> (configure continuum deployment #2 do just do clean test)
>
> With mgn-3092 it will be impossible to take one artifact commit a change to
> the head and see if that breaks any of my other artifacts without changing
> poms. As the #1 won't pickup any changes because snapshot is not explicitly
> selected.
That's the way it normally works. When a project is ready to receive
an upgraded dependency, the dependency is explicitly upgraded,
adjustments are made accordingly, it is then tested and released.
Reproducibility is the focus here, not the ease of upgrading a
project's dependencies; that's what tools should facilitate.
> I think people just overrate what snapshots provide... a non reproducible...
> non rollbackable... changes get pushed on me as a developer so i get broken
> when its incovenient to me...
This is not a problem when managed correctly. Of course, if all
dependencies are left in snapshot on trunk with multiple developers
working on various new features simultaneously, then yes, development
will be troublesome. But feature branches and the emphasis on
releasing often mitigates this.
> I work on the basic premise that the system should be in a state or
> releasability not development. Snapshots just bugger that up. And worse it
> makes people lazy. "Its only a snapshot". Not using snapshots as a norm gives
> me more power to "smack someone in the head" - if you will excuse the
> metaphor - if they are not working responsibly.
Surely having the pom control exact versions of dependencies promotes
reproducibility and releaseability? Having the command line control
them via profiles and the such moves the responsibility to the user,
thus becoming more error prone.
> IMO if its not in source control it does not count, there is no trail, no
> guarantees, no possibility of generating diffs -Perhaps mercurial or svk
> could mitigate that to some extent - and chances are no recent backups.
All source changes that occur in a snapshot are in SCM since that's
what CI builds from?
I really would like to come to a resolution of how we want version
ranges to work within Maven. This is holding up using ranges
seriously and fixing bugs relating to ranges, e.g. MNG-2994,
MRELEASE-318 and of course MNG-3092. I've got some time to be able to
work on these issues but my hands are tied until we have a clear
direction.
Does anyone from the PMC care to comment?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
