Specifying possible version statements for libraries and apps

WebFreak001 d.forum at webfreak.org
Fri Oct 8 17:01:47 UTC 2021


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:

1) having `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.

2) 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.

3) 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.


More information about the Digitalmars-d mailing list