On Apr 18, 2013, at 12:08 PM, Thomas Brettin <[email protected]> wrote:
I would like to do a minor release next week.
The primary target would be the invocation service. The current production invocation service is not aware of all of the commands as new command files were added to services after the last major build.
Also, what do you guys think about the release engineering team "owning" the release notes? Basically, when we boot up a minor release, those things scheduled for the minor release would have a short sentence like the one above. These could be for internal use only, but I thin it would be good to know in general why something got scheduled for a minor release.
Can you clarify what you mean by "owning"? It makes sense for the release team to collect and share (in whatever manner we decide, internal and/or external) the release notes, but I'm not sure how easy it will be for them to actually write the release notes. In the case above, the invocation service, the release team is intimately aware of what's going on with it, but how would the release team be expected to know what changed in all of the other services? If the developers added informative commit messages, it should be possible for the release team to read them all and summarize the changes, but that's a big if. I do think the release notes (at least in some concise form) should be shared publicly on our website so our users know what has changed. It would also be useful for the release team to keep more detailed release notes to help make us more aware of what has changed, for trouble-shooting etc. Nomi