Please, could someone confirm points 1 and 2?
softwarepills wrote: > > Thanks for your response. > > Yes, you are right. But we are now starting the development of a big > system, so till we reach a stable stage where release is posible, we have > many snaphosts. > > I was using "deterministic" applied to the update moment as now happens > that someone is working on a module and suddenly it get compile errors as > some snapshot has been updated. In that moment he may think that the error > is due to his own changes in the code of the assigned module. The result > is that many people comes to me to ask about strange behaviors of Maven. > > So, only to let it clear, my assumptions 1 and 2 are correct? > > If the answer is yes, do you think its correct to use policy=never in this > scenario? > > > Michael McCallum-3 wrote: >> >> deterministic and snapshot just don't go together... as the result of any >> update is non-deterministic and being able to undo an update if rather >> difficult. >> >> you can use range to achieve and agile deterministic release process >> where you >> can roll forward or back anytime you like but get the latest by >> default... >> >> assuming you have reasonable tests and some communication you rarely >> break >> people in this way >> >> On Thu, 02 Oct 2008 22:43:03 softwarepills wrote: >>> If i am not wrong, with unique=false and policy=daily, snaphot updating >>> follows this rules: >>> >>> 1.- Update check (and posibly update itself) is made a day after last >>> publishing in the remote repository of the single artifact being >>> checked. >>> So it could be at any time, any day, and different for every artifact, >>> as >>> they are involved in the current build (not all artifacts at the same >>> time >>> at 12:00 pm, for example). >>> >>> 2.- As said in >>> http://docs.codehaus.org/pages/viewpage.action?pageId=22585, >>> every time a new remote snapshot is published, it will overwrite a local >>> snapshot regardless of age. This is the only way to provide consistent >>> behaviour and avoid clock skew - for example, while it might make sense >>> to >>> honour a local snapshot if it were newer than the remote snapshot, it >>> may >>> be that the local one was built from older sources and so is, in fact, >>> older. >>> >>> For me, this could be very confusing in a team development process >>> (especially 2). >>> >>> I think a deterministic way of snapshot updating is preferable using >>> policiy=never. In this way you always preserve the same snaphots and, >>> eventually, you can use -U to compile with fresh snaphost and get in >>> sync >>> with the team. >>> >>> Of course, you get a deterministic way of snaphot updating at expense of >>> automatic updates, and posibilly, you can discover that one lazy >>> developer >>> has never used -U and is using very old snaphots. >>> >>> Please, any comments are welcome. >> >> >> >> -- >> Michael McCallum >> Enterprise Engineer >> mailto:[EMAIL PROTECTED] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > -- View this message in context: http://www.nabble.com/Deterministic-update-of-snapshots-tp19776315p19784075.html Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
