I think our current definition of a 'Incompatible Change' is so broad
that it is not useful for a user. I never understood why a protocol
version change should be in that list (I know, technically it is
incompatible).
Also automated release notes can never come close to human generated
release notes, however incomplete the human generated version is.
+1 if this is just a guideline and Hadoop requires a (not very long)
human generated end-user friendly release notes.
Raghu.
Nigel Daley wrote:
I'm underwhelmed by the response to this thread. Any other
input/opinions on how we track incompatibilities and create meaningful
release notes?
Nige
On Mar 12, 2008, at 12:15 AM, Nigel Daley wrote:
On Mar 11, 2008, at 12:17 PM, Doug Cutting wrote:
Nigel Daley wrote:
1. an incompatible checkbox
This really only passes the buck, doesn't it?
Ya, it passes it to the right people - the submitter and reviewer as
opposed to the committer (who is currently responsible for determining
if an issue goes in the INCOMPAT section of CHANGES.txt). We also
need to provide guidelines on what may be considered an incompatible
change.
2. a release note text box
Shouldn't folks just include CHANGES.txt message in the patch?
That's what I've always encouraged, but few are ever provided.
Perhaps Hudson can bounce patches that don't touch CHANGES.txt?
Both these would make sense if we intend to abandon CHANGES.txt and
use them instead. Is that your intent?
No, I think we need CHANGES.txt (or some equivalent) that lists ALL
the changes in the release (as opposed to the release notes that only
list the important changes). I'm told, too, that it's also convenient
to have a complete list of changes IN the workspace so that a
developer can quickly see what has been recently committed. So I
think CHANGES.txt stays. My proposal is to add an additional files
(release notes) that is auto generated from the new field in Jira.
Nige
