RPC protocol version changes are important, because they mean that clients and servers have to upgraded at the same time.
-Michael On 3/18/08 2:14 PM, "Raghu Angadi" <[EMAIL PROTECTED]> wrote: 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 >> >
