THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Work in progress...
General getting started information here
tbd
Additional Information
- command line interface information
...
BEFORE you unzip the release candidate
1a Check that Checksums are valid
Add information about tools to use, tips, and tricks for checking this information.
1b Check that PGP signature is valid
Add information about PGP tools, procedure.
...
AFTER you unzip the release candidate, but BEFORE you build
2 Check the commit ID matches the VOTE email
The idea here is to check that the commit ID in the downloaded file matches that in the VOTE email. You will use a command line terminal for at least some of these steps.
Approach 1 (clone the git repository, checkout the commit id, and compare to release candidate)
This approach uses Git commands to compare the downloaded release candidate to a cloned git repository. You will clone one copy and unzip the other copy in such a way that will "trick" Git into thinking you are comparing two versions that you have edited. (I'm missing part of the picture here. What is the end configuration you want before you use git status to compare files?)
...
If there are NO CHANGES, then the commit ID in the VOTE email matches the release candidate.
Approach 2 (download git commit from GitHub and compare to release candidate)
This approach uses the commit id from the VOTE email to download that commit from GitHub, which is then compared to the release candidate using the diff command.
...
Again, if there are NO DIFFERENCES, then the commit ID in the VOTE email matches the release candidate.
3a Check the incubator disclaimer
tbd
3b Check the file names include "incubating"
tbdCheck the unzipped release candidate to ensure the top-level distribution folders contain the word "incubating" (?)
4 Check the top-level LICENSE and NOTICE files
tbd
5 Check the source file headers
tbd
6 Check the provenance
tbd
7 Check that the source code does not include any binaries
Before building, the downloaded zip folder should contain no unexpected binary artifacts. For example, there should be no *.jar files.
There may be some "expected" binary files, such as pictures and test workflows. These should be declared in NOTICE/LICENSE if they came from third-parties, e.g., if use use a Creative Commons-licensed JPEG.
Build
8 Check for BUILD SUCCESS
detailed information about how to build (run mvn clean install command from distribution directory? send output to files using > textfile1.txt 2> textfile2.txt ?)
AFTER the Build
9 Check the dependencies
Reasons for checking dependencies: (TBR)
- Make sure dependencies are all used and declared. (Use mvn dependency:analyze and look for warnings or errors.)
- Determine if there are any mismatches between resolved dependencies and the dependencyManagement section. (Use mvn dependency:analyze-dep-mgt and look for warnings or errors.)
- Generate a list of licenses for each third-party dependency and check the licenses to make sure they meet Apache licensing requirements. (See Review Binary License below.)
- FYI, you can create a list of dependencies by module using mvn dependency:list.
Review Binary Licenses. Create a list of third-party dependencies using the license:aggregate-add-third-party plugin and review the dependency licenses.)
- In a command line interface, change to the top level directory of the distribution (e.g., apache-taverna-language-<version>-incubator).
- Run the following Maven command: mvn license:aggregate-add-third-party. (On Windows, to save the output to a file, add > filename.txt to the end of the command.)
- This command will create THIRD-PARTY.txt files in each target folder (in the generated-sources/license subfolder).
- Review the THIRD-PARTY.txt files for unknown or disallowed licenses. Note: some unknown licenses have been determined to be allowed.)
- One way to do this: cat target/generated-sources/license/THIRD-PARTY.txt | sort
10 Does the build produce the binaries
Quick check: browse the target folders and make sure there are not any extra folders. (For example, if we are voting on taverna-language there should not be any taverna-engine folders.)
Deeper check: ensure your target folders contains all the same *.jar files as those in the git repo? in the Maven repository? (Example link?)
At least one person should check that all staged JARs are the same as those built from the downloaded release candidate. (One approach is to do a recursive wget of the repository , and then compare the result of "find . -name '*jar'" in the wget-tree with */*/target/*.jar. See StackOverflow response.)
NOTE: Binary releases are considered "convenience only" and are not crucial for the vote: The source release is what everything else should be made from. However, in practical terms most people download the binaries from the Maven repository, so it is important this is checked at least once.
11 Do all the *.jar files include the word "incubating"?