Automatic Generation of ChangeLog

Hi,

This is something that has bothered me for quite a while, and so I sat
down today to see if I could learn a little more Python while solving
this problem. As far as I can see our version control system should
contain all the information we need to generate our ChangeLog. It seems
silly to manually replicate this information in both the version control
(commmit messages) and the ChangeLog. Finally, I keep forgetting to fill
in the ChangeLog. Another thing crept into my head too - it can cause
conflicts when several of us are working and the version control system
doesn’t spot how to merge.

Below is an excerpt that I generated today using a combination of git
log and a Python script I just wrote. It looks pretty good to me and
going forward I think it is the way to go. Opinions? It can be generated
over ranges too, which would make a what’s new in 0.9 easier to compile.

It currently lacks the + or - before a file name to signify creation and
deletion of new files. Other than that I think it hits everything we
currently have. Not all commit messages were formatted with this script
in mind though.

Thanks,

Marcus

2008-12-27 Geoff Hutchison babel@geoffhutchison.net

  • libavogadro/src/colors/residuecolor.cpp: Fix crash in residue coloring.
    (Bad news – residues are not avail. in new framework.) Need to sync
    residues
    with Molecule.

2008-12-27 Geoffrey Hutchison babel@geoffhutchison.net

  • cmake/modules/FindNumpy.cmake: Fix to FindNumpy to fail properly
    when Numpy
    is not available.

2008-12-27 Simon Ochsenreither <soc@desktop06.(none)>

  • libavogadro/src/pluginmanager.cpp: Fixed a typo preventing the
    extensions
    from being loaded

2008-12-26 Marcus D. Hanwell marcus@cryos.org

  • libavogadro/src/python/pluginmanager.cpp: Added missing includes since I
    removed them from the pluginmanager header.

  • libavogadro/src/pluginmanager.cpp, libavogadro/src/pluginmanager.h:
    Environment variable redux - move from four environment variables to one.
    AVOGADRO_PLUGINS can be set to point to Avogadro plugins.

2008-12-24 Marcus D. Hanwell marcus@cryos.org

  • libavogadro/src/extensions/orbitaldialog.ui,
    libavogadro/src/extensions/orbitalextension.cpp: Fixed triangle
    windings for
    negative electron isosurfaces, changed default tab in the dialog.

  • libavogadro/src/extensions/CMakeLists.txt,
    libavogadro/src/extensions/orbitaldialog.cpp,
    libavogadro/src/extensions/orbitalextension.cpp,
    libavogadro/src/extensions/orbitalextension.h,
    libavogadro/src/extensions/vdwsurface.cpp: Added the ability to
    generate VdW
    surfaces, and variants thereof. Still needs some work to tidy up the UI.

  • libavogadro/src/engines/surfaceengine.cpp,
    libavogadro/src/engines/surfaceengine.h: Start of the simplification
    in the
    surface engine. Need to add back in coloured surfaces, currently draws
    surface meshes in the specified colour.

  • libavogadro/src/engines/orbitalengine.cpp: Added more safety checks
    here.

  • libavogadro/src/extensions/orbitaldialog.cpp,
    libavogadro/src/extensions/orbitaldialog.h,
    libavogadro/src/extensions/orbitaldialog.ui: Added Van der Waals
    surface tab
    and associated functions.

  • libavogadro/src/meshgenerator.cpp, libavogadro/src/meshgenerator.h:
    Added
    the option to reverse the winding of the generated mesh. This depends upon
    what you consider to be inside and outside of your isosurface.

  • libavogadro/src/extensions/vdwsurface.cpp,
    libavogadro/src/extensions/vdwsurface.h: Added a VdWSurdface class
    that uses
    QtConcurrent to calculate a VdW cube. It may need further optimisation
    with
    binning etc.

  • libavogadro/src/engine.cpp, libavogadro/src/meshgenerator.cpp: Got
    rid of a
    few unused variables in function calls.

2008-12-24 Tim Vandermeersch tim.vandermeersch@gmail.com

  • libavogadro/src/extensions/CMakeLists.txt,
    libavogadro/src/extensions/highlighter.cpp,
    libavogadro/src/extensions/highlighter.h,
    libavogadro/src/extensions/pythonextension.cpp,
    libavogadro/src/extensions/pythonextension.h,
    libavogadro/src/extensions/pythonterminal.cpp,
    libavogadro/src/extensions/pythonterminal.h: Split python extension into 2
    extensions. One handles python extension scripts and the other one provied
    the terminal. Also add syntax highlighting to the terminal widget :stuck_out_tongue:

2008-12-24 Jordan Mantha jordan.mantha@gmail.com

  • libavogadro/src/extensions/gaussianfchk.cpp: fixed missing quotation

  • libavogadro/src/extensions/gaussianfchk.cpp: read in orbital
    energies from
    gaussian fchk files

Below is an excerpt that I generated today using a combination of git
log and a Python script I just wrote. It looks pretty good to me and
going forward I think it is the way to go. Opinions? It can be
generated
over ranges too, which would make a what’s new in 0.9 easier to
compile.

I think the best thing we can do is “reflow” the commit messages. I’d
take the raw commit message and remove any line breaks.

Doing a bit of searching turned up the “textwrap” module in Python:

Personally, while we can tar up a git directory (or grab from GitHub),
I think it would be good to add a Makefile target which can run
scripts like this, remove *.disabled, etc.

Otherwise this is a great idea. I run into conflicts merging with Open
Babel all the time. I also just removed ChangeLog from my local
Avogadro git repo.

Thanks for doing this Marcus,
-Geoff

Geoffrey Hutchison wrote:

Below is an excerpt that I generated today using a combination of git
log and a Python script I just wrote. It looks pretty good to me and
going forward I think it is the way to go. Opinions? It can be
generated
over ranges too, which would make a what’s new in 0.9 easier to
compile.

I think the best thing we can do is “reflow” the commit messages. I’d
take the raw commit message and remove any line breaks.

Doing a bit of searching turned up the “textwrap” module in Python:
textwrap — Text wrapping and filling — Python 3.12.1 documentation

I am not sure I know what you mean by reflow. I am already setting the
width of the lines if that is what you mean. It is just that I set it to
80 characters (which is standard in terminals/coding) and the mail
client did 78 or something. That is an easy parameter to adjust in the
script I wrote too - it is just over 100 lines with comments.

I have always found the GNU ChangeLog format quite useful in getting a
feel for what changed over longer periods of time. Day to day there are
RSS feeds and the git log command.

Personally, while we can tar up a git directory (or grab from GitHub),
I think it would be good to add a Makefile target which can run
scripts like this, remove *.disabled, etc.

Wouldn’t that be more suited to a script in our scripts repository?

Otherwise this is a great idea. I run into conflicts merging with Open
Babel all the time. I also just removed ChangeLog from my local
Avogadro git repo.

Thanks for doing this Marcus

It had been bugging me for a while due to conflicts, duplicating
entries, the fact that the VCS coupled with a script or two should be
able to do a better job anyway… If your main concern is the width of
the lines then that is no problem. The main missing feature is the lack
of +/- in front of files that are added or removed.

I will add the Python script to the scripts repository. It may be ugly
and suboptimal as this is the first time I ever tried writing a Python
script that was more than ten lines long… It does get the job done
though… There are other styles of ChangeLog too, and the fact that
most normal users are more interested in a much more concise
ChangeLog/what’s new since style entry.

I find git log --no-merges and git log -p --no-merges very useful too.
So I guess in many ways it is a case of deciding why the ChangeLog is
there and who it is aimed at. I am sure that this script (or a modified
form of it) will prove useful in making ChangeLogs if it is still useful
to provide them with our releases.

Thanks,

Marcus