openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <marcus.m...@wtnet.de>
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.

Marcus



>> On Dec 3, 2017, at 5:06 PM, Marcus <marcus.mail@wtnet.de> wrote:
>>
>> Am 03.12.2017 um 22:54 schrieb Jim Jagielski:
>>>> On Dec 3, 2017, at 4:25 PM, Peter kovacs <petko@apache.org> 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:
>>> RSCVERSION=420
>>> RSCREVISION=420m1(Build:9800)
>>> BUILD=9800
>>> LAST_MINOR=m1
>>> SOURCEVERSION=AOO420
>>> We could bump BUILD and LAST_MINOR for each Beta, which
>>> messes up our release numbering, or maybe we use
>>> something like
>>> RSCVERSION=420
>>> RSCREVISION=420b1(Build:9800)
>>> BUILD=9800
>>> LAST_MINOR=b1
>>> SOURCEVERSION=AOO420
>>> 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.MILESTONE		= "AOO420m1";
>> 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 <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


Mime
View raw message