octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ChangeLogs


From: Daniel J Sebald
Subject: Re: ChangeLogs
Date: Tue, 06 Jan 2009 19:24:03 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020

John W. Eaton wrote:
On  6-Jan-2009, Thomas Weber wrote:

| Okay, different proposal: how about we split the changelogs after a new
| release?
| | That is, we don't keep a current changelog but generate it at "make
| dist" time, say "ChangeLog-3.1.52". That is then added to the repository
| (or appended to the normal ChangeLog).

If we generate ChangeLog files automatically, I wasn't planning to try
to keep them in the Mercuial archive at all.  Or, as you suggest, we
could split them periodically if there is some need to do that (say
the generated file is large, and it would be useful to start fresh).
But generating a new file at each snapshot or seems too often to me

| Spelling or errors could then be
| corrected (as separate Changesets), but we wouldn't touch that file for
| normal changes.

In the mean time, where would that information be stored?  Fixing
spelling errors would be fairly easy, but I supect we would not
remember to fix more serious problems like missing information.
Probably it doesn't really matter too much anyway.  It's just the
ChangeLog...

Also, I think it is important for the "make dist" target to do everything
automatically.  Hand-editing files for a release is just plain
inconvenient (and probably unreliable).


Yes, definitely.  That is getting too far afield.  That edit might not be 
difficult, but the problem is making a release and having forgotten it; very 
messy.

What would be nice is a variant of

  hg log -style ChangeLog

that creates a single entry at the time of check in.  Then have a script append that 
short file to the top of the ChangeLog file.  Exclude the ChangeLog from checkin; then 
check it in as part of the "build-release script" in order to avoid a recursive 
or double check-in sort of thing, e.g., check in changes, then check in change to 
ChangeLog (that'd be silly)...  Or, simply have the change to ChangeLog be checked in on 
the following change and developers can go to the HTML interface to view the most recent 
version of ChangeLog (might be confusing).

Dan


reply via email to

[Prev in Thread] Current Thread [Next in Thread]