On 05/08/2011, at 11:52 AM, Adam Murdoch wrote: > On 05/08/2011, at 11:16 AM, Luke Daley wrote: > >> >> On 04/08/2011, at 10:34 PM, matthias wrote: >> >>> Actually, since you mentioned that *-SNAPSHOT is a Maven thing, would you >>> still recommend doing it in Gradle projects, or is there another Gradle >>> specific way of flagging builds as development builds? >> >> Right now, -SNAPSHOT is the best solution as it's reasonably well >> understood. >> >> However, there are camps out there that will tell you that -SNAPSHOTs are >> the work of the devil and that you should not under any circumstance depend >> on an artifact that can change. I'm yet to see to practical solution from >> this camp though. What is usually promoted is to timestamp your development >> builds and to depend on specific timestamps. > > Not commenting on whether SNAPSHOTs are good or bad, an alternative, if you > happen to be publishing to an ivy repo, is to use some of the ivy features: > > * A fixed version label on each published build (eg 1.0-SNAPSHOT), combined > with changing = true on the dependency definition. Not sure this buys you > anything over SNAPSHOT, except that you can choose the fixed label. > * A unique version for each published build (eg 1.0- plus a timestamp or > build number or some other increasing integer), combined with a version range > version="[1.0-+]" on the dependency definition. > * A unique version for each published build, combined with > version='integration.latest' on the dependency definition.
The criticism I am referring to stems from use of “changing” dependencies breaking things like git-bisect by builds being non deterministic due to dependencies being different at different points in time. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
