openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <>
Subject Re: [PROPOSAL] Public Beta for 4.2
Date Sun, 03 Dec 2017 22:05:19 GMT
I agree with the flow in the second paragraph.

As an additional note, betas are not releases, and will be described as 
being experimental. We can make up any process we like for deciding to 
make one available to beta testers.

When we think we have a production-ready beta, and build a release 
candidate derived from it, we have to follow the Apache release vote 
process, including at least three PMC members doing builds on machines 
we control etc.

On 12/3/2017 1:25 PM, Peter kovacs wrote:
> How do we then distinguish one beta build from another? By Build number? We need to track
build versions.
> If the vote is the only bad things we could use following flow:
> The last voted RC does not have to be the last beta RC. We have special beta splash screens.
Maybe an warning in about.
> When the quality of the release is production ready we close the beta, remove all beta
specials and build a last production version and that will be voted on.
> By this we have simple names, every one can follow, plus we do not break our work process.
> All the best
> Peter
> Am 3. Dezember 2017 18:40:23 MEZ schrieb Jim Jagielski <>:
>>> On Dec 3, 2017, at 10:06 AM, Patricia Shanahan <> wrote:
>>> On 12/3/2017 6:50 AM, Marcus wrote:
>>>> Am 03.12.2017 um 11:11 schrieb Peter Kovacs:
>>>>> I would put Beta into the Splash screen, but Release I would use RC
>> for for Release Candidate plus a number. So the first version would be
>> 4.2.0RC1
>>>>> If this does not break something of course.
>>>> I think this wouldn't be suitable. As soon as we have the last RC
>> which get approved, it is automatically the final release build. But a
>> RC in names and graphics is not what we want.
>>>> And doing a new build without the RC stuff cannot be done as it is
>> not what we had voted for.
>>>> The max we could do is to use RC in the filenames. Then we need
>> maybe just a rename and we have the final build. In the worst case it's
>> just a new upload with the same binary files but then with correct
>> filenames.
>>>> Marcus
>>> I am opposed even to changing file names. Anything we do between the
>> final testing and uploading to SourceForge is a risk of something going
>> wrong with the process at a point where it can affect millions.
>> FWIW, I agree. This part of the process works well enough, I think,
>> and any "improvements" are likely not worth the risks.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message