Infra - CREATE_RELEASE_WORKFLOW This file contains a description of all steps needed to create a Pivot (official, public) Release. Use it only as a sample. Note that all scripts are UNIX shell scripts, so you need a compatible environment, with installed even: - Apache Subversion client - Java JDK installed and other jar libraries dependencies, as required by Pivot - Apache Ant, as required by Pivot - Apache Maven (optional) - Apache RAT, from Apache, currently from here: http://incubator.apache.org/rat/ or use the jar under infra/lib (only for convenience put here) Memory and disk space required: - 512 MB of RAM to do the build - 1 GB of free disk space for downloaded files and temp and build artifacts Required steps: 1 - Download all Pivot files from Subversion, BUT using https, with the following command: svn co --ignore-externals https://svn.apache.org/repos/asf/pivot pivot (note that tags, dist and other main folders are not required here, so you can skip them) so now under the current folder you have all under the newly created folder "pivot" (later called "root" folder). 2 - Setup environment The Release process uses the usual pivot builds to generate binary artifacts, so it's better to update all required tools before proceed, for example at the moment the latest for Java 8 is JDK 8 Update 392, for Java 11 is JDK 11 Update 21. To buil full release, the env var PIVOT_RELEASE has to be defined with the right value, so define a shell variable for this, like: export PIVOT_RELEASE= Of course in this document has to be changed with the real release version, for example currently it's 2.1.0 in trunk, and 2.0.5 in branches/2.0.x . Some environment variables are needed for build/test tasks, so you need to define them accordingly to your environment. As a sample you can look at (but please do NOT commit changes to it): infra/bin/setup-environment-sample.sh Note that currently you need to copy its contents and paste in a terminal, or in your profile file, or run it but in a way to source its env vars in current shell, like: . ../infra/bin/setup-environment-sample.sh Note that until now, this procedure has been used only to build releases from the trunk, so to build from a branch (for example branches/2.0.x) probably only relative path should be fixed a little (probably add another ../ relative path in all folders should be enough). Anyway, it's better to keep this procedure for the default folder (trunk). Generated artifacts will be digitally signed by PGP / GPG, so the Release Manager MUST have a valid PGP / GPG sign (on its apache.org mail address), and must be published to some public key server (for example the MIT Key server), and that sign must be appended at the and of the KEYS file (under the trunk) and committed. 3 - Keep all files in synch with the repository For example sometimes with svn update from the trunk folder, or from its parent (the "root") folder and often verify with svn status -u 4 - Check svn properties From the trunk folder, run: clear && ant clean to cleanup previous build artifacts. Note that if Pivot projects (in that folder) has been imported in an IDE (like Eclipse) and compiled there, could exist a bin folder in any project, but it has to be deleted before the next step. Then check svn properties, for example run: ../infra/bin/check-svn-props.sh note that output here could be long, so could be better to redirect its output to a file (for example svn-props.out), so for example the previous command line could become: ../infra/bin/check-svn-props.sh > ../../svn-props.out and after some minute you can open that file and look at its contents (and edit it to fix things, as explained later). Note: remember to NOT commit this file in svn. Open that file with a text editor, and fix the MIME Type in every line containing "??" (without quotes) . A sample of usual types is: bxml - text/xml css - text/css gif - image/gif groovy - text/x-groovy ico - image/x-icon jar - application/java-archive , but RAT and svn (from the script just run) seems to return application/zip or application/x-java-archive jar.pack.gz - application/x-java-pack200 js - application/javascript , or its obsolete value text/javascript jnlp - application/x-java-jnlp-file jpg - image/jpeg json - application/json md, mkd, markdown - text/x-markdown (sub-class-of type="text/plain") pdf - application/pdf png - image/png scala - text/x-scala svg - image/svg+xml zip - application/zip For a full list, see here: http://www.iana.org/assignments/media-types/index.html Then, execute all commands contained in it, for example rename to .sh and make it executable do an chmod +x on it. Note that you have to run it from the trunk, so if this file is generated outside trunk you have to put a relative path to call it. After execution, maybe delete that file so it's hard to commit it as a mistake. Verify changes to be committed, with svn status -u Commit changes, with svn commit -m "Set svn props" Finally (optional), update all with svn update 5 - Check RAT on sources Optional but useful to avoid go to the end and have some files missing license headers, so all steps has to be redone ... From the trunk folder, for example run: java -jar ../infra/lib/apache-rat-.jar . > ../../rat.out Then verify its contents, fix what is needed, commit it, and restart from step 3 . Note: remember to NOT commit the rat.out file in svn. 6 - Create the tag in svn From the root folder (the parent folder of trunk), for example run: ./infra/bin/create-tag.sh for tagging code from the trunk, or ./infra/bin/create-tag_maintenance.sh for tagging code from branches/2.0.x . Important: if the tag already exist it will not be possible to proceed successfully, so you have to delete the tag by hand, and re-execute this command. Note that in some cases could be safer to try to create the release (next step) before and create the tag later, to avoid unnecessary tag removal/creation more than necessary. 6 - Create the release From the trunk folder, for example run: ../infra/bin/create-release.sh if all is good, after approx. 15 minutes, you have the release.tar.gz file (containing all the required stuff) under the current folder. Note: remember to NOT commit this file in svn, and the same for other temporary folders generated by builds (like maven, install, lib, and maybe others). 7- Prepare generated artifacts for the copy MOVE release.tar.gz outside the "root" folder in a newly created folder (for example in ../../pivot-_release), and untar/unzip it there. And maybe COPY even the KEYS file from the trunk to that folder. MOVE the folder maven at the same level of the newly created folder, and rename it for example in pivot-_maven, then make a zip/tar.gz of its bundle subfolder and then delete it (keep only the zipped version). 8 - Cleanup unnecessary files/folders from the trunk Delete all unnecessary files and folders from trunk (for example all seen in step 6), removing it by hand or with a script, or maybe doing an svn revert. 9 - Copy artifacts to Apache People Server Now, copy all artifacts on people.apache.org, so other developers can see/test them. Note that you have to create destination folders needed before the copy, for example connecting via ssh: ssh smartini@people.apache.org From the maven folder, for example run: scp ./* smartini@people.apache.org:~/public_html/pivot-_maven/ currently it contains approx. 20 MB of files. From the release folder, for example run: scp ./* smartini@people.apache.org:~/public_html/pivot-_release/ currently it contains approx. 60 MB of files. Then, verify with a Web Browser that all stuff has been copied and published, for example from here: http://people.apache.org/~smartini/ Important: the release content is really needed, but the maven content could be copied there only for convenience, so someone with access to a real maven Repository could publish them ... BUT only after the release has been voted and published. 10 - Send the Mail for the Vote Finally, send the mail to Pivot Developers mailing list (dev@pivot.apache.org) for the vote, with a minimum duration time of 3 days or 72 hours (and usually between 5 / max 7 days), but if possible with a week-end inside so people have more time to test all. ----