Generate a descriptive human-readable Change Log with every release #484

Open
ultrasquid opened this Issue Mar 27, 2013 · 3 comments

Comments

Projects
None yet
3 participants
@ultrasquid

This is something George when he released new binaries as seen on http://fontforge.org/changelog.html#change-log . As you can see, this has not been updated since last July. We know that there have been many changes since then but I don't know how to distill them down to a simple list like the change log from all the activity here on github.

Of course, this raises the question of what constitutes a release in this context, given our seeming continuous development cycle. I propose the change log be amended no less frequently than monthly, regardless of what we consider a proper release.

@davelab6

This comment has been minimized.

Show comment
Hide comment
@davelab6

davelab6 Apr 20, 2013

Member

This seems to be possible to semi-automate - https://www.google.es/search?q=generate+changelog+from+git

Member

davelab6 commented Apr 20, 2013

This seems to be possible to semi-automate - https://www.google.es/search?q=generate+changelog+from+git

@ultrasquid

This comment has been minimized.

Show comment
Hide comment
@ultrasquid

ultrasquid Jun 16, 2013

@monkeyiq Could you include a change log when you generate your Mac builds, please? I can't tell what if anything is different from one version to the other.

@monkeyiq Could you include a change log when you generate your Mac builds, please? I can't tell what if anything is different from one version to the other.

@ultrasquid ultrasquid referenced this issue in fontforge/fontforge.github.io Sep 22, 2013

Open

Change log #14

@JoesCat

This comment has been minimized.

Show comment
Hide comment
@JoesCat

JoesCat Sep 22, 2013

Contributor

Something like this really is more apt to be done by taking the time to go through all the commits and distilling what is worth keeping and what is not. Leaving it for an automated process is going to create a lot of cruft and unnecessary chatter since machines are just going to include "everything", plus there is little point in including very minor changes like a colour change or size change, and better to include all those changes acumilated into one point.

For an idea of the scale of this issue, you've more or less got a count of the issues done since we've been on github: https://github.com/fontforge/fontforge/contributors

Based on my experience of trying to update the AUTHOR credits, this issue is going to be very time consuming, but fortunately, the git patches are fairly well documented, and therefore it really only involves a lot of reading, and distilling (by the reader) the cruft from the stuff worth keeping. You won't be able to do it all in one sitting, and you'll have to do it in swatches. Another point in having a human read this is to remove all the dead-ends where we've gone down one path and backtracked - but this is more worth having pruned from release-point to release-point, of which we still haven't commited a particular date to doing yet.

Currently, I've been going through GIT history and trying to include AUTHORS, more-or-less doing two lists at a time. swatch one is starting from day0 and moving up the time-line (several months at a time) until hopefully reaching today (one day), and the second swatch is from my last reading until the last GIT update (which is about a month or two old at the moment). Based on experience with AUTHORS, I'd recommend doing something similar, starting from 2012July31 and incrementing up the time-scale a little at a time changing the timelog each time. If you don't have git access, then github still has something similar where you can increment through the pages, approximately page 40ish or 50ish thereabouts at the moment: https://github.com/fontforge/fontforge/commits/master?page=50

Contributor

JoesCat commented Sep 22, 2013

Something like this really is more apt to be done by taking the time to go through all the commits and distilling what is worth keeping and what is not. Leaving it for an automated process is going to create a lot of cruft and unnecessary chatter since machines are just going to include "everything", plus there is little point in including very minor changes like a colour change or size change, and better to include all those changes acumilated into one point.

For an idea of the scale of this issue, you've more or less got a count of the issues done since we've been on github: https://github.com/fontforge/fontforge/contributors

Based on my experience of trying to update the AUTHOR credits, this issue is going to be very time consuming, but fortunately, the git patches are fairly well documented, and therefore it really only involves a lot of reading, and distilling (by the reader) the cruft from the stuff worth keeping. You won't be able to do it all in one sitting, and you'll have to do it in swatches. Another point in having a human read this is to remove all the dead-ends where we've gone down one path and backtracked - but this is more worth having pruned from release-point to release-point, of which we still haven't commited a particular date to doing yet.

Currently, I've been going through GIT history and trying to include AUTHORS, more-or-less doing two lists at a time. swatch one is starting from day0 and moving up the time-line (several months at a time) until hopefully reaching today (one day), and the second swatch is from my last reading until the last GIT update (which is about a month or two old at the moment). Based on experience with AUTHORS, I'd recommend doing something similar, starting from 2012July31 and incrementing up the time-scale a little at a time changing the timelog each time. If you don't have git access, then github still has something similar where you can increment through the pages, approximately page 40ish or 50ish thereabouts at the moment: https://github.com/fontforge/fontforge/commits/master?page=50

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment