You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Work in progress...

General getting started information here

tbd

 

Additional 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?)

  1. Make a new directory and change to that directory (e.g., mkdir 1 ; cd 1)
  2. Git clone that-repository (which repository?? from where??)
  3. Checkout the commit id from the repository you just created: git checkout <commit_id>
  4.  rm -rf* (remove a directory? I don't understand this step.)
  5. Unzip the release candidate (e.g., apache-taverna-parent-2-incubating-source-release.zip) (into the same directory?)
  6. mv apache-taverna-"/*. (one level up) (Move the release candidate up one level? Because it zips into a new folder?) 
  7. git status

Git will then check the checksums of every file and let you know what has "changed." 

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.

  1. Search for the git commit corresponding to the email by browsing for it on GitHub. Use a URL that follows this pattern: https://github.com/apache/incubator-taverna-language/tree/<hash>, where <hash> is the commit has you want to download. 
  2. Click "Download Zip" and save the file to your computer.
  3. Make a new directory, change to the new directory, and unzip the GitHub file to the new folder. (e.g., mkdir 1 ; cd 1 ; unzip <filename>.zip)
  4. Move up a directory (cd .. ) and make a second new directory (e.g., mkdir 2)
  5. Change to the second new directory (e.g., cd 2) and unzip the release candidate (e.g., unzip release-candidate.zip)
  6. Move up one directory. When you do a directory listing (ls) you should see both of your new directories listed.
  7. Compare all files in the two new directories using the diff command:
    1. Linix: diff -uR 1 2
    2. Windows, GitBash: diff -r 1 2 (Windows CMD command line try FC)

The files that differ will be shown. If you do this after you build, make sure you don't have any target folders before diff-ing. (Run mvn clean to be sure.)

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"

tbd

4 Check the top-level LICENSE and NOTICE files

tbd

5 Check the source file headers

tbd

6 Check the provenance

tbd

7 Check the dependencies

tbd

8 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

9 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

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.)

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.

 



  • No labels