+1 for building all releases. Im not sure decoupling makes the situation better. Let's say you staged an api and implementation release. What happens if the vote passed for the api and failed for the implementation? It's the same result, if you have dependencies they need to either be bundled or voted on sequentially. Bundling seems better as most of the time, if any part fails you would want to cancel the whole thing. On Jul 20, 2015 9:43 AM, "Oliver Lietz" <[email protected]> wrote:
> On Monday 20 July 2015 16:25:14 Robert Munteanu wrote: > > On Mon, 2015-07-20 at 15:12 +0200, Oliver Lietz wrote: > [...] > > > And using a dedicated repo per artifact means less work if only one > > > of a bunch > > > fails. > > > > I actually think for 'Scripting releases' vote started by Radu this was > > the right way to approach it. There are 4 artifacts that were changed > > to support a certain use case, and they are linked together with > > dependencies. > > > > If Radu would've staged 4 linked releases it would mean 4 votes with at > > least a 4x72 hours wait. With a single aggregate release we would > > ideally get a single 72h wait and in the worst realistic scenario a > > 2x72h wait due to a vote being cancelled and a second vote being staged > > to address the objections brought up when the first release was staged. > > _n_ artifacts doesn't mean necessarily _n_ x 72+ hours. The votes can run > in > parallel and the additional effort for voters is minimal. We should build > each > artifact from tag either way and not just check sums and signatures. > > O. > > > > One more point: versions - reuse or increase? > > > Although versions are cheap for us, it confuses our users when > > > versions are > > > "missing". It's even more confusing that AEM 6.1 uses Sling i18n > > > 2.4.0 which > > > was _not_ released. So I'm for reusing here. > > > > +1 for reusing versions on cancelled votes. > > > > Robert > > > >
