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