Consider adding a changelog file
Closed this issue · 4 comments
It is a little difficult to see what changes were made between django-distill versions at the moment, it would be very useful if these would be documented in a changelog. I would recommend using the format described here: https://keepachangelog.com/en/1.1.0/.
I've thought about this, originally distill did just one job had got bug fixes so I didn't bother but over time it's had features added by request after it got a few users to the point where a changelog would probably make sense. If there's any more major features added I'll start one. The README is kept up to date and the commit comments are relatively verbose but I appreciate that diff'ing a README or reading commits it's the easiest way to stay up to date with a new version.
I see, that makes a lot of sense! Thank you for the explanation.
I think it might have been the versioning scheme that misled me, I was assuming that the new minor version releases contained new features. (I usually assume that libraries use semantic versioning – you may want to consider using it too so it is more clear when there are new major features added vs just a smaller patch.)
The versioning for distill originally attempted to follow the Django versioning system given it's directly a library for just Django (detailed at https://docs.djangoproject.com/en/dev/internals/release-process/) which is why it's generally just X.Y and not X.Y.Z (Distill was released for Django 1.X and 1.X Django was pre-semver). I could adopt it now, but, to be honest the only reason Distill gets a new release these days is very minor feature additions, bug fixes or tweaks to comply with any upstream Django changes so like with the changelog suggestion it's probably a reasonable idea if it was started many years ago, it might be of limited use now. I would use semver if there was a massive feature added or a rebuild.
I'll close this for now and consider it as mentioned above. Feel free to comment if you have further issues to raise. Cheers.