This is an automated email from the ASF dual-hosted git repository.
aharui pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/royale-asjs.wiki.git
The following commit(s) were added to refs/heads/master by this push:
new 4132467 Updated Release Steps Jobs On Jenkins (markdown)
4132467 is described below
commit 413246765d8bfb0be8187023bd2dc025dea8295a
Author: aharui <[email protected]>
AuthorDate: Thu Jun 20 10:13:53 2019 -0700
Updated Release Steps Jobs On Jenkins (markdown)
---
Release-Steps-Jobs-On-Jenkins.md | 81 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 80 insertions(+), 1 deletion(-)
diff --git a/Release-Steps-Jobs-On-Jenkins.md b/Release-Steps-Jobs-On-Jenkins.md
index e38c1fe..ef30fbf 100644
--- a/Release-Steps-Jobs-On-Jenkins.md
+++ b/Release-Steps-Jobs-On-Jenkins.md
@@ -18,10 +18,89 @@ Similarly, when GPG signatures are required, the RM must
download the artifacts
The various jobs all end by sending an email to [email protected] if successful.
If the emails are not clear, please improve them. The template for the emails
are sort of hidden in a Jenkins job configuration. Go to "Post-Build Actions"
at the bottom of the config page, then choose "Advanced Setting", then find the
"Success" email and choose "Advanced".
-### Release Step 001
+ ### Release Step 001
This step creates the release branch for royale-compiler from the develop
branch using Maven. Maven updates the develop branch to the next version
number which is why it needs a "git push". Then other release steps will
modify the release branch so the email at the end of this step requests that
the RM run two git commands to set up remote origin tracking of the release
branch.
+### Release Step 001 If Utils
+
+The "Utils" are the royale-compiler projects in the compiler-jburg-types and
compiler-build-tools. These two projects are used to process other
royale-compiler source code. Due to the way Maven works, you can't have some
sub-projects in a Maven build be tools for other sub-projects, so if you need
to compile the source in compiler-jburg-types and/or compiler-build-tools with
Maven you have to first run the main pom.xml with the "utils" profile, which
just builds those two sub-projects, [...]
+
+Fortunately, the code in the utils projects rarely changes and they have a
different version numbering scheme so we don't have to update their version
numbers on each release and thus re-release the utils projects with every
release.
+
+In theory, if the code in the utils projects changes, the developer making the
change will update the version of the utils to a next SNAPSHOT version. Then
if you skip the utils steps, one of the steps should fail because it detects a
SNAPSHOT version still in a POM. And that will remind you to run the "utils"
release steps.
+
+This step changes the SNAPSHOT versions in the POM to non-SNAPSHOT versions
and commits them. The RM must then "git push" them to the remote server.
+
+FWIW, there is a way to use Maven's release:prepare to change the SNAPSHOT
versions, but it was easier to automate using Maven's set-versions and
set-property step for this different release versioning scheme.
+
+### Release Step 002
+
+This step runs Maven's release:prepare step on the royale-compiler release
branch. This step changes the other royale-compiler project's SNAPSHOT
versions to non-SNAPSHOT versions and then tags that with the RC number. Maven
does not rely on a repo's HEAD in a release branch, it builds the release
artifacts from a tag.
+
+### Release Step 002 If Utils
+
+This step runs Maven's release:perform step on the utils projects in
royale-compiler. This results in release-able artifacts for
compiler-build-tools and compiler-jburg types.
+
+### Release Step 003
+
+This step runs Maven's release:perform step on the other royale-compiler
projects. When this step completes, and email is sent describing the set of
steps in the Ant script releasesteps.xml (in the royale-compiler repo) to run
to verify that the artifacts the CI server built are correct. This involves
downloading the Maven source and binary artifacts into a temporary folder,
building the source artifact and comparing the resulting binary artifacts with
the CI-built binary artifacts. B [...]
+
+### Release Step 004
+
+This step creates the release branch for royale-typedefs from the develop
branch using Maven. Maven updates the develop branch to the next version
number which is why it needs a "git push". Then other release steps will
modify the release branch so the email at the end of this step requests that
the RM run two git commands to set up remote origin tracking of the release
branch.
+
+### Release Step 005
+
+This step updates some properties in the pom.xml to use the release version of
the compiler jars, and set the date for all SWCs so they will be bit-for-bit
the same on any computer that builds them. I recommend using the current date
and then picking a time that represents the release number, so 9:06 for the
0.9.6 release. And 1:00 for the 1.0.0 release. The date and time isn't really
that important.
+
+### Release Step 005 If Utils
+
+This step updates a property in the pom.xml if the royale-compiler utils
version is changing.
+
+### Release Step 006
+
+This step runs Maven's release:prepare step on the royale-typedefs release
branch. This step changes royale-typedefs project's SNAPSHOT versions to
non-SNAPSHOT versions and then tags that with the RC number. Maven does not
rely on a repo's HEAD in a release branch, it builds the release artifacts from
a tag.
+
+### Release Step 007
+
+This step runs Maven's release:perform step on the royale-typedefs projects.
When this step completes, and email is sent describing the set of steps in the
Ant script releasesteps.xml (in the royale-typedefs repo) to run to verify that
the artifacts the CI server built are correct. This involves downloading the
Maven source and binary artifacts into a temporary folder, building the source
artifact and comparing the resulting binary artifacts with the CI-built binary
artifacts. Because [...]
+
+### Release Step 008
+
+This step creates the release branch for royale-asjs from the develop branch
using Maven. Maven updates the develop branch to the next version number which
is why it needs a "git push". Then other release steps will modify the release
branch so the email at the end of this step requests that the RM run two git
commands to set up remote origin tracking of the release branch.
+
+### Release Step 009
+
+This step updates some properties in the pom.xml to use the release version of
the compiler jars, and set the date for all SWCs so they will be bit-for-bit
the same on any computer that builds them. I recommend using the current date
and then picking a time that represents the release number, so 9:06 for the
0.9.6 release. And 1:00 for the 1.0.0 release. The date and time isn't really
that important.
+
+### Release Step 010
+
+This step runs Maven's release:prepare step on the royale-asjs release branch.
This step changes the royale-asjs project's SNAPSHOT versions to non-SNAPSHOT
versions and then tags that with the RC number. Maven does not rely on a
repo's HEAD in a release branch, it builds the release artifacts from a tag.
+
+### Release Step 011
+
+This step runs Maven's release:perform step on the royale-asjs projects. When
this step completes, and email is sent describing the set of steps in the Ant
script releasesteps.xml (in the royale-asjs repo) to run to verify that the
artifacts the CI server built are correct. This involves downloading the Maven
source and binary artifacts into a temporary folder, building the source
artifact and comparing the resulting binary artifacts with the CI-built binary
artifacts. Because the scr [...]
+
+At this point, the Maven artifacts are complete, and the Nexus staging
repository should be "Closed". Instructions are in the email. If some new
artifact was added to the release and not signed then Nexus will report an
error when closing the repo, and the appropriate releasesteps.xml scripts
should be updated.
+
+### Release Step 012
+
+This step is the first step to prepare the Ant artifacts that go on dist.a.o.
The ASF dist.a.o uses Subversion not Git, so this step checks out the Royale
folder from dist.a.o and prepares a folder to store the release artifacts.
+
+### Release Step 013
+
+This step creates the Ant artifacts that go on dist.a.o. It checks out the
develop branch just to get an Ant script for building, but doesn't use other
source. It grabs the source packages from Maven and uses those instead. When
this step completes, the email sent out will describe how to verify those
artifacts and sign them and upload them to dist.a.o
+
+### Release Step 014
+
+This step generates the [Vote] thread
+
+### Release Step 015
+
+This step generates the [Discuss] thread
+
+
## Future Improvements
### Uploading failures
