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.m...@wtnet.de> wrote:
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
