NEWS file management

[Martin Pool]

On  4 Sep 2006, John Arbash Meinel <john at arbash-meinel.com> wrote:

> And then the final is:
> 
> bzr 0.10.0 2006-09-04
>   IMPROVEMENTS
>   BUG FIXES
>   INTERNALS
> 
> bzr 0.10rc2
>   IMPROVEMENTS
>   BUG FIXES
>   INTERNALS
> 
> bzr 0.10rc1
>   IMPROVEMENTS
>   BUG FIXES
>   INTERNALS
> 
> bzr 0.9 2006-08-11
> 

(This is what you'll see in the 0.10.0 tarball and later.  I
think we should include the dates on the rcs as well.)

Yes, I think that's what Robert proposed and it's +1 from me.

> I'm okay with doing something like this, but I don't really know that
> the ordering is correct. Just because the final '0.10.0' won't have much
> of anything in it, while the 0.10.0rc1 will have the full log. And won't
> actually include things changed *during* rc1 => rc2. (though that goes
> in rc2, right?)

It should be very common to see

bzr 0.10.0 ...
 
  No changes from rc3

because we want to glide down to a soft landing.  I suppose the release
manager has discretion to put in things that don't need a new candidate,
such as perhaps small doc or string fixes.

To see what's new from any release to any other you just read up the
file.

-- 
Martin