Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Simultaneous Release Brainstorming


On 07.03.2018 09:22, Mélanie Bats wrote:
> Hi,
> Le 06/03/2018 à 19:56, Frederic Gurr a écrit :
>> Can someone remind me what the purpose of the second checkpoint (C2) is?
>> Why is it not a milestone instead?
> The purpose of the second checkpoint was to provide a step to
> synchronize the projects without the test phase, we will not build EPP
> packages.

With the old cadence, Oxygen Release and it's update releases had/have:
- 7 Milestones (M1-M7 for GA)
- 16 Release Candidates
  - 4 RCs for GA
  - 4 RCs for .1, .2, .3 (the first one is a warm-up, so no EPP build)
- another 2 RCs per JDK update (.1a, .3a)

=> 20 EPP builds (24 with RCs for JDK updates)

With the new cadence, a full cycle (YYYY.06, YYYY.09, YYYY.12, YYYY.03)
will have:
- 8 Checkpoints (2 per release, no EPP build)
- 4 Milestones (1 per release)
- 8 RCs (2 per release)

=> 12 EPP builds

If we'd replace the second checkpoint with a milestone, the total EPP
builds would increase to 16, which is still 4 less than before.

I'd recommend to do more testing, not (a lot) less. ;)

>> I'm a bit concerned about the "quiet week" becoming just "quiet 3 days".
>> It usually takes already 1-2 days to even fix a bug/discuss if a re-spin
>> should happen.
>> In this scenario re-spins will need to be an absolute exception - which
>> they should be anyways. So if the bug does not literally set the machine
>> on fire, user will need to wait for 13 weeks! ;)
> From my point of view, in this case we will discuss and
> delayed/reschedule an intermediate release.
> And as you said that should be an absolute exception.

How do we deal/align with extra builds for JDK updates?



Frederic Gurr

Release Engineer
Eclipse Foundation

Back to the top