gbdev / rgbds-www

RGBDS website, hosting documentation and install instructions. Built with Docusaurus, content from RGBDS man pages.
https://rgbds.gbdev.io
Other
7 stars 7 forks source link

Add version history page #63

Closed ZoomTen closed 1 month ago

ZoomTen commented 5 months ago

Just an idea, really—have all the important info for versions at a glance.

Note: this is different from the History section included in the docs of recent RGBDS releases.

Now, one could use the GitHub releases or tags page for RGBDS to find some version that was out at the time of when a project was last modified, but it being paginated makes it a bit cumbersome to find the right version.

The object version info I imagine could be useful in some situations. The info comes from the rgbds-obj crate.

Should versions.json have additional data to accomodate generating this table automatically?

ISSOtm commented 5 months ago

The object version info I imagine could be useful in some situations. The info comes from the rgbds-obj crate.

Yes, good idea.

Should versions.json have additional data to accomodate generating this table automatically?

Please do! That will avoid forgetting to add that info. The script that updates the JSON file should also be updated, too.

Rangi42 commented 5 months ago

Sounds good! I'd link to the corresponding release and the object format docs, like:

Version Release date Object version
0.7.0 2024-01-01 v9 r9
0.6.1 2022-12-03 v9 r9
... ... ...

Also with auto-generation there'd need to be a facility for special-casing some things, because 0.7.0's object version should be "v9 r9 declared, v9 r10 actual" (we forgot to update it then).

ISSOtm commented 4 months ago

Also with auto-generation there'd need to be a facility for special-casing some things, because 0.7.0's object version should be "v9 r9 declared, v9 r10 actual" (we forgot to update it then).

Store the displayable as a string (containing MarkDown, maybe?), and manually edit it for cases like that.

Rangi42 commented 4 months ago

Store the displayable as a string (containing MarkDown, maybe?), and manually edit it for cases like that.

Or have a freeform markdown Notes column; I can imagine other things we'd have to say about versions.

Version Release date Object version Notes
0.7.0 2024-01-01 v9 r9 Should have been v9 r10
0.6.1 2022-12-03 v9 r9
... ... ... ...
0.5.0-rcCar 2021-04-01 v9 r6 April Fools 2021
... ... ... ...
0.3.9 2019-11-02 v6 Does not define __RGBDS_MAJOR/MINOR/PATCH__ symbols!
... ... ... ...

Also note that we can't link to object file formats before some date, since rgbds(7) didn't exist.

avivace commented 2 months ago

@Rangi42 @ISSOtm could we start merging this in the current state?

Rangi42 commented 2 months ago

At the very least we'd need to add entries for 0.8.0 and 0.9.0-rc1. I'll just update it with the links too.

Rangi42 commented 2 months ago

Should versions.json have additional data to accomodate generating this table automatically?

Please do! That will avoid forgetting to add that info. The script that updates the JSON file should also be updated, too.

Not sure if someone should add this the PR before merge, or if you want it as-is.