openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter kovacs <pe...@apache.org>
Subject Re: [PROPOSAL] Public Beta for 4.2
Date Sun, 03 Dec 2017 21:25:08 GMT
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 <jim@jaguNET.com>:
>
>> On Dec 3, 2017, at 10:06 AM, Patricia Shanahan <pats@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-unsubscribe@openoffice.apache.org
>For additional commands, e-mail: dev-help@openoffice.apache.org

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


Mime
View raw message