On 09/11/17 20:15, Mark Thomas wrote: <snip/>
> The proposed release is: > > The proposed 1.1.0 release based on RC2 is: > [ ] Broken - do not release because... > [ ] Approved - go ahead and release as 1.1.0 I'm undecided. >From a functional, policy and packaging point of view I don't have any concerns. However, test JARs seem fairly pointless to have in Maven Central and there is benefit in providing the various binaries via Maven Central. While I don't want to delay the release unnecessarily, I'm leaning towards an RC3 with a set of uploads to the Nexus staging repo that aligns with the 1.0.15 release. While I could probably figure out how to do that manually, just re-rolling the release is probably going to be quicker. Thoughts? Comments? Feedback on the review below - particularly the website also welcome. Detailed review follows. Mark Java version ------------ The minimum Java version is 6 but Daemon can't be built with Java 6 (the Maven toolchain requires Java 7). That should be OK but merits additional checks. Checking one of the class files in commons-daemon-1.1.0.jar it is version 50 as expected. Unit tests ---------- The test code isn't a unit test, it is a sample. Maven Central ------------- It doesn't do any harm uploading the test JARs to Maven Central but I'm leaning towards excluding them in future. The binary and native src distributions for 1.1.0 were not uploaded to Maven Central (strictly they were but were then removed before the repo was closed). The 1.0.11 to 1.0.15 releases did include those distributions. There are benefits to having them on Maven Central so I'm leaning towards including them in future. Integration testing ------------------- Windows with Tomcat 7.0.82 Tested by replacing the Windows binaries with those from Commons Daemon 1.1.0. - Digital signatures are valid (Symantec code signing) - Passed simple smoke test running on Java 6 - Configuring Java 9 specific options didn't prevent running on Java 6 (as expected) - Java 9 options used when running on Java 9 (needed to remove endorsedDirs setting - as expected) Linux with Tomcat trunk - Warnings compiling jsvc (no change from 1.0.15) - Runs under Java 8 - Runs under Java 9 Packaging --------- I compared the contents of various artefacts in the 1.1.0 release with the equivalent from 1.0.15: - commons-daemon-n.n.n-bin-windows.zip - No ia64 dir (as expected) - Otherwise file/dir names the same - Differences in files all expected - commons-daemon-n.n.n-bin.tar.gz - no apidocs/src-html directory (looks OK) - differences in generated Javadoc files (expected) - Otherwise file/dir names the same - Differences in files all expected - commons-daemon-n.n.n-native-src.tar.gz - CHANGES.txt removed as expected - Otherwise file/dir names the same - Differences in files all expected - commons-daemon-n.n.n-src.zip - CHANGES.txt -> changes.xml (expected) - Maven source layout changed slightly (expected) - Otherwise file/dir names the same - Differences in files all expected Overall I'm pleasantly surprised. With the time between releases, changes in the release process and my unfamiliarity with both Maven and the release process I was expected some packaging issues but all looks to be OK. Web site -------- Not part of the release but since I'm here... The link for "Javadoc (SVN latest)" just points to the latest release. Should this point to a CI build, be removed or something else? What is the purpose of the Jira report? Do we need to add some more fix versions, remove the report or something else? RAT report suggests we should add an ASF header to HOWTO-RELEASE.txt but that is a minor issue I'll fix shortly. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
