Skip to content

Loading…

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

Open
ultrasquid opened this Issue · 3 comments

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
fontforge member

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

@ultrasquid

@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
Open

Change log #14

@JoesCat

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
Something went wrong with that request. Please try again.