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 > >
