On 9 Mar 2015 12:10, "Andy Seaborne" > Could you explain why that is a "-1", not "0" or even a conditional "+1"? > > Release notes are useful to some people but it does not affect the question of whether the release process has been executed correctly.
I was not sure of the practise here, and would have called it +0, but didn't as you labelled that as "Don't care". I care! :-) I thus did -1 to flag this for other voters, knowing that this would not necessarily block the release if there were no other -1s chiming in. You would need to make a new RC+VOTE if you want to fix it in the distribution. If the majority think its OK to go out with outdated release notes that is fine with me, so as such you can think of it as a conditional +1. I found the release execution to otherwise be correct, but you said it was a "major release" and then I would expect any included release notes to reflect that. > We have two significant new modules. People are using them from development. Creating this release has been a significant amount of work with several "last minute" things delaying the release. Would having an action plan to deal with the issue be sufficient for you? I will be happy with this if the others are OK with the outdated release notes in the downloads. > Proposal: > > If they are not going to be maintained, and we have JIRA which we do use, I propose we retire all the ReleaseNotes*. They are not universal across the modules anyway. +1, for the future just include link to the fixed URL of changes within the download, avoiding duplication and manual updating. >> Not sure which 'everything' to test.. so I tested Fuseki 2 binary distribution. > The source-release and the build. AKA can it run the test suites. Everything is is a convenience. As this is the first Fuseki 2 release (which also has a UI I believe is not tested by the build) I tested it explicitly. Agree that manual testing of "everything" would not generally be feasible beyond the build tests :-)
