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 Mon, 04 Dec 2017 18:59:42 GMT
Am 04.12.2017 um 13:11 schrieb Jim Jagielski:
> Good to know! Thx.
> I do have a question about the BUILD number...
> Say we release 4.1.5 and that build number is 9799. We then
> release start doing betas and RCs for 4.2.0 and use 9800,
> 9801 and 9802. We then find out we need to release a 4.1.6.
> Is that BUILD number now 9803?

in the past we have increased the build ID with every build that was 
done; regardless if it was successful at the end or which branch was 
build. I was a kind of total general consecutive number.

Of course we can change this behavior in a way that is better suited for 
us nowadays.


>> On Dec 3, 2017, at 5:06 PM, Marcus <> wrote:
>> 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. *)
>> Example:
>> // 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:
>> Apache_OpenOffice_4.2.0-Beta1_Linux_x86-64_install-rpm_en-US.tar.gz
>> *)
>> 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.
>> Marcus
>>>> 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 <>
>>>>>> 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
>>>>> which get approved, it is automatically the final release build. But
>>>>> 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
>>>>> 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