[PROPOSAL] Public Beta for 4.2

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Public Beta for 4.2

Peter Kovacs-3
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 <[hidden email]>:

>
>> On Dec 3, 2017, at 10:06 AM, Patricia Shanahan <[hidden email]> 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: [hidden email]
>For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Public Beta for 4.2

Jim Jagielski

> On Dec 3, 2017, at 4:25 PM, Peter kovacs <[hidden email]> 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.

>
> 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 <[hidden email]>:
>>
>>> On Dec 3, 2017, at 10:06 AM, Patricia Shanahan <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Public Beta for 4.2

Patricia Shanahan
In reply to this post by Peter Kovacs-3
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 <[hidden email]>:
>>
>>> On Dec 3, 2017, at 10:06 AM, Patricia Shanahan <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Public Beta for 4.2

Marcus (OOo)
In reply to this post by Jim Jagielski
Am 03.12.2017 um 22:54 schrieb Jim Jagielski:

>
>> On Dec 3, 2017, at 4:25 PM, Peter kovacs <[hidden email]> 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 <[hidden email]>:
>>>
>>>> On Dec 3, 2017, at 10:06 AM, Patricia Shanahan <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Public Beta for 4.2

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?

> On Dec 3, 2017, at 5:06 PM, Marcus <[hidden email]> wrote:
>
> Am 03.12.2017 um 22:54 schrieb Jim Jagielski:
>>> On Dec 3, 2017, at 4:25 PM, Peter kovacs <[hidden email]> 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 <[hidden email]>:
>>>>
>>>>> On Dec 3, 2017, at 10:06 AM, Patricia Shanahan <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Public Beta for 4.2

Pedro Lino-3
Hi Jim, all


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


Wouldn't it be possible for the Build number to make some sense?

It would be much easier if build number was related to the actual version? How about Build 41510 for 4.1.5 RC1, 41520 for RC2, etc? To make sure the build is greater than 9800 I added a 5th digit that could even be used for something else...

This applies also to other version numbers in files

https://bz.apache.org/ooo/show_bug.cgi?id=126603


Just my 2 (non-dev) cents
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Public Beta for 4.2

Marcus (OOo)
In reply to this post by Jim Jagielski
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 <[hidden email]> wrote:
>>
>> Am 03.12.2017 um 22:54 schrieb Jim Jagielski:
>>>> On Dec 3, 2017, at 4:25 PM, Peter kovacs <[hidden email]> 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 <[hidden email]>:
>>>>>
>>>>>> On Dec 3, 2017, at 10:06 AM, Patricia Shanahan <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Public Beta for 4.2

Andrea Pescetti-2
In reply to this post by Jim Jagielski
On 04/12/2017 Jim Jagielski wrote:
> 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?

This is an interesting scenario. The way it has worked so far are:

1. Only one development line is active.

2. For any stable release, the build number is higher than the previous
release.

3. The update system, based on your version (not build number), tells
you the build number and the URL of the latest available version. I am
fairly sure -but can't double-check now- that if the reported build
number is higher than the build number of the version you are currently
using, the update is triggered (so you see the "Updates available"
notification).

Now, can it work if we break assumption 1?

We are not interested in update URLs for Beta releases.

Having to release, say, a 4.1.6 when we already have 4.2.0-RC1 out is
really an edge case. Still, if this happens, I would:
- Just update the build number as you suggest
- Pay attention to the update feeds to avoid that feeds for 4.2.0 report
the existence of 4.1.6.

This would need a lot of care and future maintenance though, so my best
advice is: just keep supporting one development line and once we release
4.2.0-RC1 don't look back. At that point, don't release any 4.1.x
releases any longer.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123