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 <j...@jagunet.com>:

On Dec 3, 2017, at 10:06 AM, Patricia Shanahan <p...@acm.org> 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: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to