I would like to suggest adding some kind of standard metadata format to declare which custom versions (maybe also debug versions?) an application or library consumes and defines. This could be used as documentation for others, to know what kind of versions exist and may be used for example for auto completion and static analysis to see if typos in versions have been made.
I was thinking about this because issues like this could be avoided: https://github.com/das-developers/das2D/issues/2 (all builtin versions would be included in the list by default, could lint the list for not clashing the builtin versions)
I'm thinking about a few different ways how this could be realized:
version = X;or
// version = X;in the head of D files.
Advantage: This would be the most easy one to adapt as some projects maybe already use some kind of structure like this. Could work out of the box for some projects already. Can easily add documentation in the form of comments.
Disadvantage: in a long block of versions you could introduce typos when duplicating them in conditional blocks.
have it integrated in dub.json/dub.sdl like
"availableVersions": ["A", "B", "C"]
Advantage: no extra file needed for DUB projects, making for a clean project. Can be inherited / shown easily and parsing can trivially be extended. Having them defined exactly once can prevent typos with full certainty.
Disadvantage: Needs to be added into all projects, no documentation in JSON format possible. (or more verbose format needed, but writing long text in JSON strings is not fun once quotes and new lines are introduced) Not applicable to non-DUB projects.
have a dedicated .ddoc/.txt/.sdl/.json/.whatever file to list versions and documentation.
Advantage: Works universally in projects, can for example be included in the IDE's own project format. Having them defined exactly once can prevent typos with full certainty.
Disadvantage: Needs to be added into all projects. Not being bound to any build system means it's unclear where versions go and how dependencies/dependants work.
Which ones of those would you prefer and do you think this is a good idea in general?
Once settled on a format it would be relatively easy to add suggestions and linter errors for it to editors and LSP clients or make a dedicated tool for it.