On Mon, 27 Jul 2026 at 09:31, Yishay Weiss <[email protected]> wrote: > > Adding to the earlier list of tooling improvements from RC2: > > 4) Vote-email templates (Jenkins jobs and Ant release scripts) now include > the release tag name, commit id, and GitHub tree URL for each repo covered by > the release. > > 5) The two utility approve scripts (ApproveJBurgTypes.xml and > ApproveBuildTools.xml) gained an optional verify-source-matches-tag target. > It is skipped by default; passing -Dcompiler.dir=<path-to-royale-compiler> > triggers a git archive of the tagged subdirectory and diffs the file list > against the extracted source ZIP. Reviewers who want extra provenance > assurance can opt in without affecting the default flow.
This is not an optional step. The only way reviewers can establish whether a source file is allowed to be shipped is to compare it against the source, because it is only when content is added to the source repo that the license conditions can be checked. If a reviewer has not checked that the files in the source bundle all came from the source repository, in my view that does not count as a full review, and should be noted in the comments. > ________________________________ > From: Yishay Weiss <[email protected]> > Sent: Friday, July 24, 2026 2:48 PM > To: [email protected] <[email protected]> > Subject: Re: [DISCUSS] Discuss Release Apache Royale Compiler JBurg Types > 1.1.1 > > A few small tooling issues surfaced while validating RC2. None affect the RC > itself — flagging here for transparency and follow-up on develop: > > 1. Consumer integration build missing from ApproveJBurgTypes.xml. > The vote email asks voters to verify that other compiler POMs can consume the > new version, but the approval script only builds the utility source package. > I ran it manually with: > > cd royale-compiler > mvn clean install -Dcompiler-jburg-types.version=1.1.1 > > I've added an optional verify-compiler-integration target on develop that > automates this when -Dcompiler.dir=<path> is provided. The next vote email > template will document it. > > 2. Vote summary referenced fields that don't apply. > The approve target echoed "README is ok: ${readme.ok}" and "RELEASE_NOTES is > ok: ${releasenotes.ok}", which never get set because this artifact ships > neither file, so the reply had unresolved ${...} placeholders. Cleaned up on > develop. > > 3. "beta-quality" wording in vote templates. > The vote-email templates in releasecandidate.xml / releasesteps.xml still > described releases as "beta-quality". Given we're moving to 1.0.0, I removed > that paragraph and softened the "not in PMC" phrasing on develop. > > None of the above blocks RC2 — the artifact itself is correct and > reproducible. > > Thanks, > Yishay > ________________________________ > From: Apache Royale Release <[email protected]> > Sent: Friday, July 24, 2026 11:26 AM > To: [email protected] <[email protected]> > Subject: [DISCUSS] Discuss Release Apache Royale Compiler JBurg Types 1.1.1 > > This is the discussion thread. > > Thanks, > Yishay Weiss
