Below are the steps one should follow This is the workflow to create a new Apache Daffodil release.
...
release for either the Daffodil or the Daffodil VS Code Extension project.
You must be a Daffodil "Committer" to execute some of the steps of this workflow.
Initial Setup
The following steps must only be performed only once:
...
Signing Keys
Release files must be signed with an OpenPGP compatible key. If you do not already have a key for signing Apache releases, follow the developer instructions in the Daffodil KEYS file in the Daffodil repository to generate a key and add it to the KEYS file. Follow the contributor workflow and create a review branch and pull request to commit your changes to the KEYS file.
Once merged, the KEY file should also be copied to the release/inucbator/daffodil/KEYS
file in the apache-dist repo (see below). Your key fingerprint should also be added to perform the following steps:
Clone the Apache Dist Daffodil release directory, copy the KEYS file, and commit it:
Code Block language bash $ svn checkout https://
...
dist.apache.org
...
/repos/dist/release/daffodil/ daffodil-dist $ cp daffodil.git/KEYS daffodil-dist $ cd daffodil-dist $ svn ci -m "Update Apache Daffodil KEYS"
Add your key fingerprint to https://id.apache.org. To get your fingerprint, run the following:
Code Block language bash $ gpg --fingerprint KEYID
Send your key to a keyserver via the command
For more information on creating a signing key, visit How to OpenPGP and Signing Releases.
SBT PGP
The sbt-pgp plugin is required to publish signed releases. Add the following to the file ~/.sbt/1.0/plugins/pgp.sbt
to enable usage of the plugin:
Code Block |
---|
addSbtPlugin("com.jsuereth" % "sbt-pgp" % "1.1.1") |
In most cases, no other configuration should be necessary–the plugin should automatically find and use the signing key created above.
Checkout the Apache Dist Repository
...
:
Code Block language bash
...
$
...
Staged files are created in the dev
directory and are moved to the release
directory once approved by the Incubator Project Management Committee.
Creating a Release Candidate
...
Code Block | ||
---|---|---|
| ||
$ ./scripts/release-candidate.sh |
...
Commit the files in Apache dist, for example:
Code Block | ||
---|---|---|
| ||
svn add dev/incubator/daffodil/*
svn ci -m "Stage Apache Daffodil (incubating) 2.0.0-rc1" |
...
Push the git tag
Code Block | ||
---|---|---|
| ||
git push --tag asf 2.0.0-rc1 |
Update the Website
Create a new release file in the _site/releases/
directory in the Daffodil Site Repository, updating the page to include a summary of the changes and links/descriptions of the bugs that were fixed in this release. Parameters that must be set because this is a release candidate include:
Code Block |
---|
released: false
artifact-root: "https://dist.apache.org/repos/dist/dev/incubator/daffodil/2.0.0-rc1/"
checksum-root: "https://dist.apache.org/repos/dist/dev/incubator/daffodil/2.0.0-rc1/" |
Follow the steps in the README in that repository to publish the new release page.
Daffodil Release Vote
With the release files published for staging and a website created, you may now start a vote on these files. To do so, send an email to dev@daffodil.apache.org base on the following example, making sure to update all links and version numbers:
Code Block | ||
---|---|---|
| ||
Subject: [VOTE] Release Apache Daffodil (incubating) 2.0.0-rc1
Hi all,
I'd like to call a vote to release Apache Daffodil (Incubating) 2.0.0-rc1.
All distribution packages, including signatures, digests, etc. can be
found at:
https://dist.apache.org/repos/dist/dev/incubator/daffodil/2.0.0-rc1/
Staging artifacts can be found at:
https://repository.apache.org/content/repositories/orgapachedaffodil-1000/
This release has been signed with PGP key 033AE661, corresponding to
slawrence@apache.org, which is included in the repository's KEYS file.
This key can be found on keyservers, such as:
http://pgp.mit.edu/pks/lookup?op=get&search=0x033AE661
It is also listed here:
https://people.apache.org/keys/committer/slawrence.asc
The release candidate has been tagged in git with v2.0.0-rc1.
For reference, here is a list of all closed JIRAs tagged with 2.0.0:
https://issues.apache.org/jira/browse/DAFFODIL-1864?jql=project%20%3D%20DAFFODIL%20AND%20fixVersion%20%3D%202.1.0%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
For a summary of the changes in this release, see:
https://daffodil.apache.org/releases/2.0.0/
Please review and vote. The vote will be open for at least 72 hours
(ends on Sunday, 11 February 2018, 12 Noon EST).
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
My vote: +1
Thanks,
- Steve
|
After at least 72 hours, if the VOTE passes, create a RESULT thread announcing the passage.
Incubator Release Vote
You must now create a VOTE thread on general@incubator.apache.org to get approval from the Apache Incubator for release. This email should be the same as the above, but with the following at the beginning of the email, again making sure to update the links to the vote and result thread.
Code Block | ||
---|---|---|
| ||
Subject: [VOTE] Release Apache Daffodil (incubating) 2.0.0-rc1
The Apache Daffodil community has voted and approved the proposed
release of Apache Daffodil (Incubating) 2.0.0-rc1.
We now kindly request the Incubator PMC members review and vote on this
incubator release.
Daffodil is an open source implementation of the DFDL specification that
uses DFDL schemas to parse fixed format data into an infoset, which is
most commonly represented as either XML or JSON. This allows the use of
well-established XML or JSON technologies and libraries to consume,
inspect, and manipulate fixed format data in existing solutions.
Daffodil is also capable of the reverse by serializing or "unparsing" an
XML or JSON infoset back to the original data format.
Vote thread:
https://lists.apache.org/thread.html/4b71db31a6a420098a18139a046c5493d5685137251b4727736a9f18@%3Cdev.daffodil.apache.org%3E
Result thread:
https://lists.apache.org/thread.html/f883421a96deffee80e59bd2fbbf07062dfe0ee26e4c4c4cfa194ba5@%3Cdev.daffodil.apache.org%3E
|
After at least 72 hours, if the VOTE passes, create a RESULT thread announcing the passage.
Promoting to Final Release
The following steps should be taken once the incubator vote passes.
In the Apache dist directory, move the release candidate files to the release directory
Code Block | ||
---|---|---|
| ||
svn mv dev/incubator/daffodil/2.0.0-rc1/ release/incubator/daffodil/2.0.0/
svm ci -m "Release Apache Daffodil (incubating) 2.0.0" |
In the Daffodil git repository, create a signed git tag based on the release candidate tag
Code Block | ||
---|---|---|
| ||
git tag -as -m "Release v2.0.0" rel/v2.0.0 v2.0.0-rc1
git push --tag asf rel/v2.0.0 |
...
Modify the website release page to have the following parameters:
Code Block |
---|
released: true
artifact-root: "http://www.apache.org/dyn/closer.lua/incubator/daffodil/2.0.0/"
checksum-root: "http://www.apache.org/dist/incubator/daffodil/2.0.0/" |
...
Give approximately 24 hours for the release files to sync to mirrors and maven central.
gpg --send-keys KEYID
It is important for your keys to be signed by other trusted developers to create a web of trust. See Signing Keys and Getting Your Keys Signed.
For more information on signing keys, visit How to OpenPGP and Signing Releases.
Container Software
To improve reproducibility and minimize the effects and variability of the user's environment, release candidates should be created using the "Daffodil release candidate container". Note that although commands to use this container have been tested with podman
, you should be able to replace podman
with docker
if you would rather use it instead. Install the container software of choice using your systems package manager or from the container software website. For example:
Code Block | ||
---|---|---|
| ||
$ sudo dnf install podman |
Versions of podman known to work include 3.4.1 (on RedHat) and 3.4.2 (on Ubuntu)
Versions of docker known to work include 20.10.11 (on Ubuntu 20.04).
Preparing for a Release Candidate
The following steps should be performed prior to creating a release candidate:
- Create a [DISCUSS] thread on dev@daffodil.apache.org to make a decision as a community if the timing is correct for a release and what open issues should be resolved for a release. Ensure there is at least 72 hours for discussion before moving forward.
- Upon agreement, someone should volunteer to be the "Release Manager" to take the responsibility to prepare the release candidate.
- Check
containers/release-candidate/Dockerfile
for dnf/npm packages with out of date versions (especially sbt and yarn installs). Dependabot does not automatically update these. If out of date, create and merge a pull request to update the versions.
Prior to creating the release candidate, the version of the project still contains the
-SNAPSHOT
keyword. Create and merge a pull request to remove this-SNAPSHOT
keyword in preparation for a non-snapshot release.The new version should not contain an
-rcX
suffix--the suffix is automatically added to release candidate artifact file names where necessary by the release candidate container.
Creating a Release Candidate
Below are the steps one should follow to create a new release candidate.
Build the Daffodil release candidate image:
Code Block language bash $ podman build -t daffodil-release-candidate /path/to/daffodil.git/containers/release-candidate/
This may take 10-15 minutes the first time, but should be significantly faster in subsequent runs unless something changes in the image where a full rebuild is needed.
This requires substantial free disk space. If you need to control where podman puts this storage, you can specify the --tmpdir, --root, and --runroot directories as ABSOLUTE paths. (Relative paths are known to cause issues.). Note that if you specify these additional flags on this podman build command you must also specify them for the podman run command below.
Run the daffodil release candidate container. The command is here, but before running it, prepare the necessary inputs (below) that you will need to provide it when prompted. There are timeouts, and if you wait to dig these things up when prompted they will time out and you'll need to start over. Also, you must run this command in a standard terminal window that supports cursor-positioning via ANSI escape sequences, which it uses heavily.
Code Block language bash $ podman run -it --privileged --group-add keep-groups --rm \ -v ~/.gitconfig:/root/.gitconfig \ -v ~/.gnupg/:/root/.gnupg/ \ -v ~/.ssh/:/root/.ssh/ \ --hostname daffodil.build \ daffodil-release-candidate
Note: This must be run from an ordinary xterm/terminal window, as it uses escape sequences to position the cursor and text. It will not work in an Emacs shell buffer.
Note that the
-v
option is used to bind mount files/directories from the host system in the container so the container has access to git configurations and gpg/ssh keys.The
--dry-run
option can be provided to the very end of the above podman command (e.g.... daffodil-release-candidate --dry-run
) to perform a test without publishing any artifacts. An optional parameter can also be provided to perform a dry run with a different GitHub repository and branch (e.g.... daffodil-release-candidate --dry-run user/repo@branch
).The
--entrypoint /bin/bash
option can be provided before the last argument in the above podman command (e.g.... --entrypoint /bin/bash daffodil-release-candidate
) to interactively view the configuration settings and manually run the daffodil-release-candidate script. This can be useful for debugging the container or testing changes.
- The container will periodically ask for user input (e.g. usernames, passwords) to sign and publish release files. Dig out all these before you run the script above so you are ready to provide them when prompted. Note that none of the prompts have a default value - you always must type something before pressing the Enter key. Prompted information includes:
- The project to release. Options are either "1" for Daffodil or "2" for Daffodil VS Code Extension.
- Private OpenPGP key to use for signing release artifacts. The long format and identify of all available private keys are displayed in a list. Enter the number of the key to select which to use for signing. Ensure you select the key associated with your apache.org email address and not some other identity.
- Release candidate label. For example: "
rc1"
if this is the first release candidate. This should not include the release version number (e.g.2.0.0-rc1
) – it should only contain thercX
part.
- Git name and email (e.g. "John Doe" and "john.doe@company.com"). This is the name (first name and surname) and email you want to show up as the "Committer" when the release script creates a git tag or commit, which could potentially be different than what is the the bind mounted
.gitconfig
file. This is not your GitHub or Apache credentials--simply the name and email address you use for Daffodil commits.If you have Github's Email Privacy setting on, be sure to use the private email provided in your Github Settings, otherwise the
complete-release
script will fail.
- Apache username and password. This is the username and password credentials used to log in at https://id.apache.org.
- GitHub SSH key password. The Daffodil repository is cloned using SSH authentication. If your SSH key is password protected, you may be prompted for that password.
- Private GPG password (also called the 'pass phrase'). The release process signs artifacts with your private GPG key–you will be prompted for a password to enable it to use your private key to sign these artifacts.
- The project to release. Options are either "1" for Daffodil or "2" for Daffodil VS Code Extension.
After entering the necessary information the script will run. It may output a few error messages that are not true errors about gpg using your private key as the default key for signing, and a few others also. The script will perform the actions listed below.
- Create a zip of the source
- Create helper binaries. For Daffodil this inclues a .tgz, .zip, .msi, and .rpm. For daffodil-vscode this inclues a .vsix.
- Create sha512 checksum and GPG signatures (".asc" files - ASCII armored detached signatures) of the above files.
- Place the above files in the Apache dist dev directory. These svn files are not committed until further action is taken.
- Create a signed git tag. This tag is not pushed until further action is taken.
- For Daffodil only, create javadoc and scaladoc docs in the daffodil site repository docs directory for this release and create a commit. This commit is not pushed until further action is taken.
For Daffodil only, stage jars/poms to https://repository.apache.org along with their GPG signatures (".asc"), MD5 checksums (".md5"), and SHA1 checksums (".sha1").
Once the script completes, at that point the terminal window has a shell prompt where commands you type are being given to the running container.
You must complete the remaining steps without exiting this shell.
- Create a zip of the source
- You should verify the existence of the generated files. Note The script will list the files and locations to verify. This includes:
Verify the checksums and signatures are created in the Apache dist directories and are ready for commit, for example:
Code Block $ cd /root/daffodil-dist/ $ ls -R $ svn status
A script that can be adapted to verify the signatures and checksums is in the comments of this page.
Verify the git tag is attached to the correct commit in the project repo, for example when releasing the Daffodil project:
Code Block language bash $ git -C /root/daffodil/ log -n 1
For Daffodil only, verify the javadoc and scala docs for the version to be released exist in the daffodil site repository.
This can be done with git log:
Code Block language bash $ git -C /root/daffodil-site/ log -n 1 -p
or via the file system:
Code Block $ cd /root/daffodil-site/ $ ls -R
- For Daffodil only, verify the all the expected jars/poms at https://repository.apache.org/ exist.
A specific release of Daffodil may or may not be cross-compiled for more than one version of Scala. (As of Daffodil 3.3.0, only Scala 2.12 is supported, but future releases may support more than one version of Scala.)
For all modules, verify the proper scala version(s) exists, and for each scala version, there exists a jar, javadoc jar, sources jar, and pom, and for each of those files there exists the GPG signature (".asc" armored ASCII file), and the associated md5 and sha1 checksums of all of these. To do so, visit https://repository.apache.org/, login in the top right using id.apache.org credentials, select "Staging Repositories" on the left, and find theorgapachedaffodil-XXXX
repository (there should be only one). Inspect the "Content"
tab to make sure the appropriate jars are uploaded and appear valid.
A script which can be adapted to download and verify the signatures and checksums for the contents of repository.apache.org is in a comment on this page.
- If any of the above do not look correct, perform the following steps:
- For Daffodil only, "Drop" the stages files at https://repository.apache.org--log into that URL with id.apache.org credentials, check the box for the Daffodil staging repository, and click "Drop" at the top.
- Type
exit
to close the container. All files/commits created in the container will be deleted.
- Fix the issue and repeat the "Create Release Candidate" process from the beginning.
- For Daffodil only, "Drop" the stages files at https://repository.apache.org--log into that URL with id.apache.org credentials, check the box for the Daffodil staging repository, and click "Drop" at the top.
- After verifying all is correct, follow the instructions to complete the release candidate. These steps include:
Run the command:
Code Block language bash $ /root/complete-release
All the previous commands have prepared commits and tags in the three repositories (Apache Dist, Daffodil, and Site). Running this command will push those commits and tag to the remote repositories.
- For Daffodil only, "Close" the staged files at https://repository.apache.org--log into that URL with id.apache.org credentials, check the box for the Daffodil staging repository, and click "Close" at the top.
- Type
exit
to close the container.
Update the Website (For Daffodil Release)
The previous steps have pushed the new scaladoc and javadoc docs to the Daffodil Site Repository repository. In order for your local sandbox copy of that repository to have this same content, you must fetch those updates, which is typically done via:
Code Block | ||
---|---|---|
| ||
$ cd daffodil-site
$ git checkout main
$ git fetch --prune asf
$ git rebase asf/main |
The most recent commit should then show the addition of new scaladoc and javadoc docs to the site.
Create a new release file in the site/_releases/
directory, updating the page to include a summary of the changes and links/descriptions of the bugs that were fixed in this release. The procedure for gathering the bugs fixed is as follows:
- Go to JIRA's Releases page to view only the unreleased versions (need to be a PMC member - ask a PMC member if you are not one).
- If you see only one unreleased version in the list, fill out the Version name text box of the next unreleased version above the list and click Add to add a new unreleased version to the list.
- If the release candidate version has a green bar that is not completely filled in, you need to move some issues to the next unreleased version. Click on the release candidate's version to view its issues.
- Click on the number of "Issues to do" above the list of issues (the number will be non-zero if the green bar was not completely filled in).
- Click on "View in Issue Navigator" above the list of issues.
- Do a Bulk Change to move these issues to the next unreleased version (Top Right: Tools > Bulk Change, select all issues, click Next, select Edit Issues, click Next, select Change Fix Version/s, select Replace all, pick the next unreleased version, and so on).
- Go back to JIRA's Releases page and click on the release candidate's version again. If the number of "Issues in progress" is not zero, you also need to click on it and move its issues to the next unreleased version too (repeat steps 5-6 and come back to this step.
- Click on "Release Notes" near the top of the page.
- Click on "Configure Release Notes", change "Please Select Style" to Text, and press Create.
- Scroll down to the bottom where you will find a text area with the project release notes ready to be copied to another document.
- Copy the release notes to the new release file in the
site/_releases/
directory, change all "[DAFFODIL-XXX]" to "{% jira XXXX %}", change all indentation and category lines to markdown format, and save your changes. - For changes that need more description (e.g. big features), create sections on the release page and add those descriptions.
For the section on Dependency updates, the following command shows the changes or new dependencies that should be mentioned.
Code Block language bash $ git diff v1.0.0 -- project/Dependencies.scala
You will of course change "v1.0.0" in that command to the tag of the prior release to the one you are preparing.
Parameters of the release file (near the top) that must be set because this is a release candidate include:
Code Block |
---|
release: rc1
|
Look through the git log for any commits with the "Deprecation/Compatibility" keyword and copy that section of the commit message to the deprecation/compatibility section in the release notes.
Additionally, update the Unsupported Features page if any features/errata are now supported in this release.
Follow the steps in the README in the daffodil-site repository to test and publish the new release page.
Release Vote
With the release files published for staging and a website created, you may now start a vote on these files. To do so, send an email to dev@daffodil.apache.org based on the following example, making sure to update all links and version numbers. Make sure to update all links and use "plain text" editing for the email. HTML editing often leads to broken links or incorrect formatting.
If releasing the Daffodil VSCode Extension, make sure to use the correct project name, remove the "staging artifacts" wording and link, and reference GitHub Issues instead of JIRA.
Note that the link to
daffodil-issues-2.0.0
should be created at https://s.apache.org, linking to the unreleased version in JIRA's Releases page showing the list of issues fixed by this release.
Note the https://dist.apache.org link instead https://downloads.apache.org because this is a pre-release.
Code Block | ||||
---|---|---|---|---|
| ||||
Hi all,
I'd like to call a vote to release Apache Daffodil 2.0.0-rc1.
All distribution packages, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/daffodil/2.0.0-rc1/
Staging artifacts can be found at:
https://repository.apache.org/content/repositories/orgapachedaffodil-1000/
This release has been signed with PGP key 36F3494B033AE661, corresponding to slawrence@apache.org, which is included in the KEYS file here:
https://downloads.apache.org/daffodil/KEYS
The release candidate has been tagged in git with v2.0.0-rc1.
For reference, here is a list of all resolved JIRA issues tagged with 2.0.0:
https://s.apache.org/daffodil-issues-2.0.0
For a summary of the changes in this release, see:
https://daffodil.apache.org/releases/2.0.0/
Please review and vote. The vote will be open for at least 72 hours (Sunday, 11 February 2018, 12 Noon EST).
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
Thanks,
- Steve
|
When committers test a new release candidate and vote for approving (or not approving it), they usually post a checklist showing what they verified to explain their vote. A very thorough person might check off an exhaustive checklist like the below one, although many use shorter checklists:
Code Block | ||||
---|---|---|---|---|
| ||||
+1
[OK] verified signature of git tag
[OK] verified hashes and signatures of source and helper binaries
[OK] verified signatures use key in KEYS with apache email address
[OK] verified source has no unexpected binary files
[OK] verified source and git tag are same minus KEYS file
[OK] verified source and helper binaries include LICENSE/NOTICE/README
[OK] verified LICENSE/NOTICE/README look correct
[OK] verified online JavaDoc and ScalaDoc docs look correct
[OK] compiled source and ran all tests & ratCheck (LANG set to both en_US and de_DE)
[OK] verified jars built from source have same content as helper binary jars
[OK] verified dependencies in helper binaries are same as in maven poms
[OK] tested bin & msi & rpm installers and checked "daffodil --version" output from each
[OK] verified some public and private DFDL schema projects pass tests calling new release |
If any issues are discovered during the vote, the vote can be canceled and an rc2 created after the issues have been fixed and merged. After the message below has been sent, follow the same procedures as if the vote didn't pass.
Code Block | ||||
---|---|---|---|---|
| ||||
Officially canceling the VOTE for 2.0.0-rc1. I'll create an rc2 and start a new VOTE.
VOTE thread:
https://lists.apache.org/thread.html/ra2fcf855251ed00c354abf29dfce73177fa3bf3a3705c5714f1aaabd%40%3Cdev.daffodil.apache.org%3E
Thanks,
- Steve
|
After at least 72 hours, if the VOTE passes (at least 3 binding +1 votes and more positive than negative votes), create a RESULT thread announcing the passage and listing the binding and non-binding vote totals (you may omit those with zero totals) and vote breakdown. Binding votes are votes from PMC members and non-binding votes are votes from non-PMC members, which includes committers and community members. For example:
Code Block | ||||
---|---|---|---|---|
| ||||
The VOTE to release Apache Daffodil 2.0.0-rc1 is now closed.
The vote passes with:
3 binding +1
1 non-binding +1
The VOTE thread:
https://lists.apache.org/thread.html/c8df54668fbcb7b8285f3e2cc524eac7cb82a721fa823ea5ae7edbe3%40%3Cdev.daffodil.apache.org%3E
The vote breakdown is:
+1 First Last (binding)
+1 First Last (binding)
+1 First Last (binding)
+1 First Last
Thanks to everyone who voted! |
If the VOTE does not pass, fix the issues, "Drop" the release at https://repository.apache.org (for Daffodil only), and repeat the "Create Release Candidate" process from the beginning with a new rcX number. Note that creating a new release candidate will automatically delete the files from the previous release candidate.
Promoting to Final Release
The following steps should be taken once the above vote passes.
Move the release candidate files to the release directory. (This prompts for your apache account password. It may prompt you about plaintext password storage. If so, it works even if you answer "no".)
For Daffodil:
Code Block language bash $ svn mv -m "Release Apache Daffodil 2.0.0" \ https://dist.apache.org/repos/dist/dev/daffodil/2.0.0-rc1/ \ https://dist.apache.org/repos/dist/release/daffodil/2.0.0/
For Daffodil VS Code Extension:
Code Block $ svn mv -m "Release Apache Daffodil VSCode Extension 2.0.0" \ https://dist.apache.org/repos/dist/dev/daffodil/daffodil-vscode/2.0.0-rc1/ \ https://dist.apache.org/repos/dist/release/daffodil/daffodil-vscode/2.0.0/
Make a new clean clone (for good measure) and create a signed git tag based on the release candidate tag. You need your KEYID (See step 3b above) for your Apache signing key, and you will be prompted for the pass-phrase for your Apache signing key.
Make sure to use daffodil-vscode.git when releasing Daffodil VS Code Extension.
Code Block language bash $ cd /tmp $ git clone git@github.com:apache/daffodil.git daffodil-2.0.0-rc1 $ cd daffodil-2.0.0-rc1 $ git tag -as -u KEYID -m "Release v2.0.0" v2.0.0 v2.0.0-rc1^{} $ git push origin v2.0.0
You can delete the /tmp clone directory at this point.
- For Daffodil only, "Release" the staged files at https://repository.apache.org - log into that URL with id.apache.org credentials, check the box for the Daffodil staging repository, and click "Release" at the top.
- For Daffodil only, deploy the RPM to the Apache Artifactory repository:
- Download the RPM convenience binary for this release (from
https:
//dist
.apache.org
/repos/dist/release/daffodil/2
.0.0/)
- Visit https://apache.jfrog.io/ and login using Apache credentials
- Click "Artifacts"
- Click "daffodil-rpm"
- Click "Deploy"
- Click "select file" and select the previously downloaded RPM
- Click "Deploy"
- Download the RPM convenience binary for this release (from
- For Daffodil only, update JIRA's Releases page to mark the version as released (need to be a PMC member - ask a PMC member if you are not one).
Wait approximately 24 hours for the release files to sync to mirrors and Maven Central (for Daffodil only). To verify, check here
https://search.maven.org/ (ensure you can see daffodil libraries with versions matching all supported Scala versions; select one and verify the release versions exist in at least the sbt version)
https://www.apache.org/dyn/closer.lua/daffodil/2.0.0 (change 2.0.0 to the new version, pick a mirror, and ensure the files exist)
For Daffodil only, once the mirrors have synced, make the following changes to the daffodil site repository and publish them:
Modify the release page to have the following parameters:
Code Block release: final date: <date of release>
Modify the site/doap.rdf file to include the release date and version, for example:
Code Block language xml <release> <Version> <name>Apache Daffodil</name> <created>2018-02-18</created> <revision>2.0.0</revision> </Version> </release>
Update the symlink to the latest Javadoc and Scaladoc docs in the site/docs directory (note that there is no forward slash at the end of
latest)
.Code Block language bash $ cd site/docs/ $ ln -sfn 2.0.0 latest
- Follow the steps in the daffodil-site README to test and publish the new release page.
- Visit https://reporter.apache.org/addrelease.html?daffodil (must be a PMC) and add the release version and date. For Daffodil VS Code Extenion, prepend "VSCODE-" to the version.
Now that the download URLS of the previous release point to the archive, remove that release from Apache dist to free up space on mirrors:
For Daffodil:Code Block $ svn delete -m "Archive Apache Daffodil 1.0.0" \ https://dist.apache.org/repos/dist/release/daffodil/1.0.0/
For Daffodil VS Code Extension:Code Block $ svn delete -m "Archive Apache Daffodil VS Code Extension 1.0.0" \ https://dist.apache.org/repos/dist/release/daffodil/daffodil-vscode/1.0.0/
Publish VS Code Extension to Marketplace:
For this access the to ASF VS Code publisher via your Visual Studio Marketplace account. This can be done by making a INFRA ticket in JIRA and tag Gavin McDonald. After you have been added you should be able to follow the steps below.
- Download the latest VSIX file from https://daffodil.apache.org/vscode/
- Navigate to https://marketplace.visualstudio.com/vs in a browser.
- Login to your Visual Studio Marketplace account that has access to the ASF VS Code publisher.
- Click the button "Publish extensions" in the upper right of the page.
- Click the 3 dots ("...") next to "Apache Daffodil VS Code Extension". Select "Update"
- Either drag and drop the download VSIX file from a window explored. Or select "Explore" and select the downloaded VSIX file.
- Once the file uploads finish the version area should say "Verifying <VERSION>".
- Make once the version is verified, the version expected is displayed.
Announce the release
Send an announcement email from your apache.org email address to announce@apache.org, dev@daffodil.apache.org, and users@daffodil.apache.org, (note: send three separate emails instead of one email with multiple TO/CC's), with the below template.
To send to announce@apache.org, your email app needs to be configured. Settings can be found on Apache's Committer Email page. For Gmail, you can request to "Send Email as" and with Thunderbird, you can add a new Outgoing SMTP Server and create a new Identity (Manage Identities) to send from the relay.
Make sure to update links and use "plain text" editing for the email. HTML editing often leads to broken links or incorrect formatting.
Make sure to update the project name and description when releasing the Daffodil VS Code Extension
Code Block language text title \[ANNOUNCE\] Apache Daffodil 2.0.0 Released The Apache Daffodil community is pleased to announce the release of version 2.0.0. Notable changes in this release include <short summary of changes>. Detailed release notes and downloads are available at: https://daffodil.apache.org/releases/2.0.0/ Apache Daffodil is an open-source implementation of the DFDL specification that uses DFDL data descriptions to parse fixed format data into an infoset. This infoset is commonly converted into XML or JSON to enable the use of well-established XML or JSON technologies and libraries to consume, inspect, and manipulate fixed format data in existing solutions. Daffodil is also capable of serializing or "unparsing" data back to the original data format. The DFDL infoset can also be converted directly to/from the data structures carried by data processing frameworks so as to bypass any XML/JSON overheads. For more information about Daffodil visit: https://daffodil.apache.org/ Regards, The Apache Daffodil Team
- The same or a similar announcement can also be posted to the DFDL Workgroup News page here: https://github.com/OpenGridForum/DFDL/wiki/DFDL-Workgroup-News (Done by a DFDL Workgroup member, like Mike B).
Send a tweet from the @ApacheDaffodil twitter account, mentioning the release version, highlights of changes, and a link to the release page. You will need to be invited/accept, via Tweetdeck, permission to tweet from the account. At which point you may compose the below style of message from Tweetdeck.
Code Block The @ApacheDaffodil team is excited to announce the release of version 2.0.0! Notable changes include <short summary of changes>. Details and downloads at https://daffodil.apache.org/releases/2.0.0/
- Various published DFDL schemas and examples will, most-likely, want to be updated so that they automatically reference the latest release of Daffodil from their main branch.
For some Daffodil releases DFDL schemas must also have updated library versions. (E.g., for release 3.3.0, in the build.sbt the scalaVersion must be "2.12.15" to enable Java 17 to work.) This is generally a good time to update other library versions used by the DFDL schema to newer versions consistent with those used by Daffodil, which are in daffodil/project/Dependencies.scala (e.g., junit and junit-interface).
Send an announcement email to announce@apache.org, dev@daffodil.apache.org, and users@daffodil.apache.org, (note: send three separate emails instead of one email with multiple TO/CC's), with the following template:
Code Block | ||
---|---|---|
| ||
Subject: [ANNOUNCE] Apache Daffodil (incubating) 2.0.0
The Apache Daffodil (incubating) community is pleased to announce the
release of version 2.0.0.
Release notes and downloads are available at:
https://daffodil.apache.org/releases/2.0.0/
Daffodil is an open source implementation of the DFDL (Data Format
Description Language) specification that uses DFDL schemas to parse
fixed format data into an infoset, which is most commonly represented as
either XML or JSON. This allows the use of well-established XML or JSON
technologies and libraries to consume, inspect, and manipulate fixed
format data in existing solutions. Daffodil is also capable of the
reverse by serializing or "unparsing" an XML or JSON infoset back to the
original data format.
For more information about Daffodil visit:
https://daffodil.apache.org/
Regards,
The Apache Daffodil Team
|
...