vsc_ast.py: Implement version_label

[gunnarx]

As discussed in #44

[erikbosch]

Have we discussed what to do with the syntax file now when we at least partially can generate documentation. Keep up-to-date for now, or let it degrade until we are ready to replace it with a generated version?

[gunnarx]

Have we discussed what to do with the syntax file now when we at least partially can generate documentation. Keep up-to-date for now, or let it degrade until we are ready to replace it with a generated version?

The syntax file ought to be removed from the VSC repository since the IFEX documentation now provides all that information. The VSC project can optionally refer to IFEX for the definition of the language used for the service descriptions.

[miketsukerman]

Sorry, I haven't participated in the discussion and maybe this question has been clarified already. Only wanted to ask why can't we use simply

version: Optional[str] = str()

Where version has special format, for instance https://peps.python.org/pep-0440/#version-scheme. Instead of minor_version, major_version and version_label etc.

[gunnarx]

Rebased.

[gunnarx]

Sorry, I haven't participated in the discussion and maybe this question has been clarified already. Only wanted to ask why can't we use simply

version: Optional[str] = str()

Yes, a standard version string containing <major>.<minor>.<patch> might be an option that gives us the major/minor meaning. I will leave it open for now but if someone really feels they want that as an alternative way to write it, then we could support both.

Where version has special format, for instance https://peps.python.org/pep-0440/#version-scheme. Instead of minor_version, major_version and version_label etc.

I generally like the idea of reusing an existing specification but:

1. That particular specification is too complicated, in my opinion. If that spec is used then all cases need to be supported and supported correctly, or a complex explanation needs to be written to explain which features are used and what they mean.
2. It is much simpler to support separate major and minor numbers and have client-server compatibility logic based on plain semantic versioning.
3. Then, to allow any freely decided format for the extra-information string simplifies implementation further. Inside a particular company process or in some other special case, the string format might be defined in some way and local tools programmed to interpret it, but many standard tools will be able to just ignore it and that simplifies the implementation.

[gunnarx]

NOTE! Optional patch version still missing. see #44