On Tue, Mar 16, 2010 at 4:18 AM, Benson Margulies <[email protected]> wrote: > If the answer is, 'always make a branch,' then that's the answer. It > is not a popular answer with the developers I'm supporting. I wish > there was some alternative involving controlling snapshot updates per > g/a instead of per repository. --offline prevents unwanted updates, > but it also prevents wanted updates of other, unmodified, things, and > new dependencies.
Offline is the answer short of a branch. In any maintained and stable build, there should generally be no other snapshot dependencies than your project own ones. Using external snapshot dependencies should be an exception rather than a rule. Kalle > On Tue, Mar 16, 2010 at 5:54 AM, Stephen Connolly > <[email protected]> wrote: >> On 16 March 2010 04:25, Ron Wheeler <[email protected]> wrote: >> >>> Benson Margulies wrote: >>> >>>> I have this feeling that I'm missing something terribly obvious. >>>> >>>> 1: grab a tree and make some changes. >>>> 2: mvn. Now you've got SNAPSHOT versions in your local repository >>>> 3: someone else checks in a change and runs mvn deploy. Now the >>>> snapshot repo has jars newer than the local repo. >>> >>> 4: run mvn and download those over top of the local mods. >>>> >>> >> Only if you have the update rule for your snapshot repos set to check every >> time. >> >> If you are working on a branch, then run maven in offline mode to prevent >> having to worry about picking up other versions that somebody elese has >> deployed >> >> >>> >>>> Without patching all the version numbers, is there a best practice or >>>> standard mechanism to stay out of this pickle? >>>> >>>> >>> What is the pickle? You have the latest version which is what you want if >>> the person doing the deploy has done the deploy for a reason. >>> If the version deployed is not better than the version that you have >>> locally, you beat the crap out of the guy who deployed a version when they >>> shouldn't have. >>> >>> If people deploy crap into repositories, you will have a problem >>> eventually. >>> If you put your version into your source management, the other person would >>> have based his mods on yours or at least noticed the conflicts before he >>> deployed. >>> >>> Collaborative software development has to be done collaboratively. >>> >>> Ron >>> >>> >>> --------------------------------------------------------------------- >>>> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
