Add a version information endpoint to the application

[kMutagene]

Both the API and the client application should contain version info. I imagine it like this:

• the major API version can be shown in the backend via routing: /IAnnotatorAPI/v1/YOUR/ROUTE/HERE
• The client should have either an info tab or footer () that displays the version of the deployed application (e.g. 0.1-beta atm), and this should be populated via a call to the backend.
• Bonus points if this gets automated via FAKE release notes versioning

[Freymaurer]

I am currently thinking about how we can implement this without creating a lot more overhead for us during development. And i would really like to discuss the following with you:

I changed Route.builder to:

Allowing us to easily create paths with the versioning integrated. This is then followed up in Server.fs by:

This is a big one, so let me explain. All Fable remoting APIs are now forwarded to mainApiController, which has one forward for each fable remoting API we use (This will be important as soon as we have any form of authentication). Each forward can use any integer as version for the api so we have to test for released Api versions. In this example we obviously only have version 1 so we respon with a error message should someone try to access any version except 1. When we release new API version we can just add the released version like |1 |2 -> api stuff or even have a pattern matching function that we can use for all API to improve scaleability. Anyhow, the version is then parsed to the routebuilder and the api itself where we have multiple options to manage versioning, but i think i would approve of the following way the most:

This allows us to easily change only the functions that changed with the version with minimum effort. Let me hear what you think about it.

Edit: As far as i can see this, this could kill the fable remoting automatic documentation.

[kMutagene]

Looking good so far, documentation may look like it fails, but its actually hosted under the same /v1 path. Maybe rename the webapp function to something more expressive like createAPIWithVersion.

[kMutagene]

After further investigation on how Fable.Remoting builds the routes, using /vXYZ is not the wa to go, rather a new API interface like this: IAnnotatorAPIv1 {} ; IAnnotatorAPIv2 {}

[Freymaurer]

@kMutagene regarding the following:

Bonus points if this gets automated via FAKE release notes versioning

Is this what you meant?

Build.fs

Server/Version.fs

The Information is parsed from RELEASE_NOTES.md

[Freymaurer]

I hope this will get me all the bonus points. i will write an extensive part about this in the README.md soon, but for now:

• dotnet fake build -t release will check if README.md exists and if it does it compares the current commits to the last commit used for the release notes. It will then add the latest commit messaged to the latest release notes.
  This is the default behavior and will not increase the number of the SemVersioning.
• The tags semver:patch, semver:minor, semver:major as in dotnet fake build -t release semver:patch will add a new release with either increased major, minor or patch number.
• The function will also do some light key word searching do determine for obvious commit messages if it belongs to the Additions, Deletions or Bugfixes category.
• At the moment FAKE has an error in parsing the SemVer of the release notes (ReleaseNotes.load does not parse SemVer correctly fsprojects/FAKE#2557) so the lates commit for each release is currently saved in "Additions", this will be removed as soon as the SemRev.MetaData is fixed.
• After RELEASE_NOTES.md is updated, the function will update Version.fs with the latest release SemRev and this is then used for the client app version, etc.

[kMutagene]

Thats pretty cool @Freymaurer ! To get the last bonus point, automate the GitHub release draft via FAKE as well (while i like automation, i would really like to be able to proofread releases beforehand), so you have a release draft with the correct version tag etc. when you execute the release target. But don't get me wrong, thats already good stuff right here 💯

[Freymaurer]

Okay, i added an extra fake target dotnet fake build -t githubdraft, which will parse the latest release in RELEASE_NOTES.md and create a draft from these notes. It will upload all files in .assets as asset and add a predefined text (in build.fs) after the latest release notes.

Example: