Am 03.12.2017 um 22:54 schrieb Jim Jagielski:
On Dec 3, 2017, at 4:25 PM, Peter kovacs <pe...@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 <j...@jagunet.com>:
On Dec 3, 2017, at 10:06 AM, Patricia Shanahan <p...@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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
