Open ericop opened 1 year ago
Not sure how specifically we got into this situation, but seems that big old "Upcoming..." commented-out section wasn't addressed as part of those releases? cc @MithrilJS/collaborators as I've been away too long to have a working memory of what led up to it (and so I'm not really a good resource to look into this).
When we switched to pr-release we switched from a handwritten change log to an automated one.
The automated log is currently output here: https://github.com/MithrilJS/mithril.js/blob/release-v2/docs/recent-changes.md
This is also mirrored by the github release notes: https://github.com/MithrilJS/mithril.js/releases
The site now links directly to github releases when you click on the changelog in the nav - but that changelog.html link still resolves... We should probably figure out a way to merge the past and present logs so it is consistent.
pr-release just prepends the release notes to the existing changelog file, so we could probably inject the old content at the bottom of that file. PR release will leave the existing content untouched and simply prepend. Then we can have the docs feed from the recent-changes.md
file instead of the old changelog.md
file.
@JAForbes "We should probably figure out a way to merge the past and present logs so it is consistent." This right here is the hard part, how we should reconcile it.
Also, the migration of the changelog to the docs repo throws yet another wrench into this problem. This is why, for now, I'm just directing people to https://github.com/MithrilJS/mithril.js/releases.
Can we just wget https://raw.githubusercontent.com/MithrilJS/mithril.js/refs/heads/release-v2/docs/recent-changes.md
in the docs CI?
@JAForbes No, because the docs needs notified somehow of that new version.
I have Dependabot set to check daily and open an ungrouped Mithril pull request on update, but of course, ideally, there'd be some sort of automation there to directly push the version update.
Edit: and one of the complicating factors is it'd have to also make sure not to update it backwards, which could happen if we add automation for releasing older branches. Adding that protection now would mean that, if we did that in the future, we wouldn't need a careful commit dance to avoid clobbering it later or an immediate docs revert to fix it after every non-latest patch. (This would allow us to partially support multiple versions at the same time.)
Hi mithril team, I have been away for a while (since 2.0.3) and saw we are on https://mithril.js.org/ . So I went to the change log to see what's new, but it didn't say. Can we get this updated?