openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <>
Subject Re: [PROPOSAL] Public Beta for 4.2
Date Sun, 03 Dec 2017 22:06:38 GMT
Am 03.12.2017 um 22:54 schrieb Jim Jagielski:
>> On Dec 3, 2017, at 4:25 PM, Peter kovacs <> wrote:
>> How do we then distinguish one beta build from another? By Build number? We need
to track build versions.
> Agreed... Right now we have:
> RSCREVISION=420m1(Build:9800)
> BUILD=9800
> We could bump BUILD and LAST_MINOR for each Beta, which
> messes up our release numbering, or maybe we use
> something like
> RSCREVISION=420b1(Build:9800)
> BUILD=9800
> for betas and then switch back to 'm1.. m2...' for the RCs.

at least the download scripting is knowing a beta release and is 
prepared. *)


// Beta Release: General properties.
DL_BETA.VERSION			= "4.2.0-Beta1";
DL_BETA.NAME			= "4.2.0 Beta1";
DL_BETA.BUILD			= "1234";
DL_BETA.SVN_REV			= "r1234567";
DL_BETA.REL_DATE		= "2017-Dec-XX";

So, a typical filename could be:

At least the scriping has parts to process to handle special steps and 
areas fot a beta release. However, of course it need to be tested and 
likely to be adapted. But don't worry I will take care ot this.


>> 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
>> 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
>>> 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:

View raw message