I think the time to collect this data is when we schedule something for the release. We just ask what changed. When they reply, we ask them if they can paste it into the release notes file or some other location. I'll do this next week.
Ok, sounds reasonable.
Ideally, we'd have a more complete list of what's changed for internal use, with a subset of that list communicated to external users, because there's stuff that affects us internally but won't affect outside users. But maybe that's getting too complicated.
Nomi
For genome annotation: what changed is the urls were changed to use '
base.us' the production servers as well as the protocol was switched from http to https.
Tom
I don't think it has been strictly enforced in the past, but I also think we should start requiring it. I know I completely forgot to update the release notes for Trees, which I should have done... Perhaps we should provide a very simple module checklist of what we require for a module to enter the release process, really just as a guideline to help developers remember everything that needs to be done.
Some of us had started adopting the convention of placing notes in a file named RELEASE_NOTES.txt in the root directory of each module.
Release-team mailing list
Release-team@lists.kbase.us
https://lists.kbase.us/mailman/listinfo/release-team
Release-team mailing list
Release-team@lists.kbase.us
https://lists.kbase.us/mailman/listinfo/release-team