We already had this discussion so many times and it always turns to non ended complicated discussion with very complicated cases which NEVER happen here.... So the most important is: We must take it easy and avoid overthinking!..... +1 for every night a master snapshot or every master changes. but please keep it simple!!!!
On Fri, 11 Jan 2019 at 06:34, Dan Tran <dant...@gmail.com> wrote: > how about just deploy nightly snapshot of active 'main' branch ( ie > master)? > > -D > > > On Thu, Jan 10, 2019 at 9:03 AM Robert Scholte <rfscho...@apache.org> > wrote: > > > Now that we use branches actively, it is way more important where a > > SNAPSHOT is coming from. > > I've seen it too often that people thought they were testing with a > > version from a specific branch, but that it was redeployed with another > > version. > > The first steps are done to rewrite the pom-file during publication, and > > that might be exactly what we need here: when we're on a branch, the > > branchname should be added to the version. > > Call it work in progress for better support. > > > > thanks, > > Robert > > > > On Thu, 10 Jan 2019 10:50:57 +0100, Stephen Connolly > > <stephen.alan.conno...@gmail.com> wrote: > > > > > On Thu, 10 Jan 2019 at 09:11, Mickael Istria <mist...@redhat.com> > wrote: > > > > > >> Hi, > > >> > > >> Eclipse m2e, as a consumer of Maven as a library, would love to see > the > > >> latest HEAD from master published automatically as SNAPSHOTs soon > after > > >> every change is made. This seems like a requirement to enable > continuous > > >> feedback from m2e to Maven. > > >> Publishing some other branches or commits doesn't seem interesting to > > >> Eclipse m2e at the moment. > > >> > > > > > > My point is that we need a clearly defined policy as to exactly what > > > branch(es) are automatically pushed and when. > > > > > > That policy could be *one* of: > > > * "master" if there are SCM changes detected on Sunday at 00:00 UTC > > > * "master" if there are SCM changes detected at 00:00 UTC > > > * "master" as soon as SCM changes are detected > > > * "integration" as soon as SCM changes are detected > > > * etc > > > > > > We just need to be crystal clear exactly what policy we are following. > > > Right now the policy we are following is: > > > > > > * Manually from whatever branch is appropriate and only when there is a > > > request for them to be published. > > > > > > There are good and valid reasons for any of these policies (or indeed > > > other > > > alternative policies). The problems occur if you try to mix policy. > > > > > > For example, if I as a developer know that snapshots could be published > > > at > > > any time then I can choose between `always` and `never` as the update > > > policy depending on whether I want to focus on diagnosing issues on a > > > consistent base or discovering issues on shifting sand. > > > > > > If I know that snapshots will only ever be published once a week then I > > > can > > > leave the update policy at the default of daily because I'll need to > > > rebuild my mental context on the next week anyway and it's only the > first > > > build on Monday's that will have the time kill. > > > > > > So the thing that we need to do is decide if we want to change our > > > policy, > > > if yes, then decide what we want to change it to *and* both implement > it > > > consistently and publish it clearly. > > > > > > Finally we have the ASF legal requirements that mean we need to clarify > > > to > > > all that -SNAPSHOTs are not actually releases and are only made > available > > > for validation prior to VOTE threads... because currently -SNAPSHOTs > are > > > rare this is not a big issue... if we have the CI pushing -SNAPSHOTs > at a > > > regular cadence the risk of *users* starting to use -SNAPSHOTs as > > > releases > > > rises so we would need to find ways to mitigate such risks > > > > > > > > >> > > >> Cheers, > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
