Open bpas247 opened 6 years ago
I'm not sure that a changelog should be a priority. In a way, the git commit log on master is kinda acting as a changelog.
While an automated changelog sounds nice, I don't think that there's any point in having a changelog except when making a release.
A manual change log that needs to be updated with each PR and commit would demand a lot of extra work, which I think wouldn't be worth it.
Semantic versioning is great, this has been used already for the proof of concept release: https://github.com/Chris-Johnston/Easier68k/releases
I think that for the next release v0.2.0
we could include a changelog that highlights the most important changes made from the previous release, like all of the opcodes added. This pattern could continue for all the major releases to follow.
@Chris-Johnston
I think that for the next release v0.2.0...
How should we organize the features for each release? We could just use GitHub milestones and projects for this.
A milestone would do for planning features for a release. We had made a few when this was just a school project for the due dates and those were closed, but new ones could be added.
@Chris-Johnston
A milestone would do for planning features for a release.
Should we open up a new issue to discuss the v0.2.0 release and milestone?
Currently, we don't have a change log. We can go two ways with this:
We also need to decide what versioning scheme to use (if that hasn't been previously decided). I personally prefer Semantic Versioning.