[boost] Re: Fixes and additions for each release

From: Edward Diener (eddielee_at_[hidden])
Date: 2002-11-02 09:55:36

"Daryle Walker" <dwalker07_at_[hidden]> wrote in message
news:5D5F1E38-EE31-11D6-80FF-0003939C8002_at_snet.net...
> On Thursday, October 31, 2002, at 1:24  PM, Beman Dawes wrote:
>
> > At 05:18 PM 10/30/2002, Edward Diener wrote:
> >
> >> Nonetheless, some sort of record of changes from release to release
> >> would be
> >> most valuable. It would be a great help to those who need to update
> >> their
> >> own implementations based on Boost's implementations, especially, as
> >> in my
> >> case, when changes have been made to a Boost implementation for one's
> >> own
> >> private version and a new release of Boost is issued.
> >>
> >> Needless to say it would also be a benefit to those who are using a
> >> new
> >> Boost release and want to understand explicitly what has changed from
> >> the
> >> previous release and what new functionality has been added and where.
> >>
> >> I know from my own experience that it is hard for developers to keep
> >> track
> >> of every specific change as they develop a product, but I see little
> >> to no
> >> indication of changes made between releases of Boost in its various
> >> libraries, and find this lack of information disconcerting and
> >> unproductive
> >> to Boost usage.
> >
> > Perhaps developers should be encouraged to add a change list to their
> > documentation, listing changes between releases which might be of
> > interest
> > to users. For consistency, call it changes.html and put it in the
> > library's
> > documentation directory. With a link from the main docs page.
>
> Can we use automation to help us?  We could use CVS to print all the
> changes to every file (as well as file adds and removals) in commit
> order and use that as a template to remind developers for the change
> notes.
>
> Anyway, I probably wouldn't remember all the changes I've done and you
> would have to do something like this to remind us.

Would it really be that hard for a developer to keep two lists: one a list
of bugs fixed and the other a list of changes in functionality ? I wouldn't
expect line numbers in files for either list, but just items which others
could refer to in order to understand what has changed from release to
release.

I have almost always kept such lists as notes when working on
re-distributable software. I understand that many developers don't do this,
but it takes a few seconds to make such notes.