release-candidate-v0.2.1

Release candidate v0.2.1.

Steps to prepare this release:

1. git checkout a clean copy of the master branch,
2. Prepare a compiled binary which can be created using the vsce marketplace tool using:
   • :> cd ~/.vscode/extensions/vscode-fileheader
   • :> vsce package
3. Prepare release at https://github.com/Nos78/vscextensionode-fileheader/releases/new which tags the branch head and uploading the binary .vsix file.
   • Branch tag for this release candidate: release-candidate-v0.2.1
4. Release diectly to Marketplace with vsce publish

v0.2.1 Release notes

Release date 2022-10-21
We recently added two new fields to our comment header block, author's @Email and @description. Like all the other fields, these where added into the template (now templates plural) and populated whenever the user inserts a header. It has come to mind that some users might not want these additional fields, preferring the template(s) to look the same as they used to. They could edit the template, but faced with a big warning not to edit, they may be reluctant to do so...

• Updated the configuration settings with two new checkboxes, grouped under 'rendering options'. These check boxes (default is ON) allow the user to turn off the @Email and @description tag when inserting a new comment header. This allows the user to turn o

Note: This does not affect existing headers; existing fields can be deleted manually if unwanted.

There are a lot of options now in the extensions configuration, and it might become obvious when experimenting that you have to restart VS Code in order to see the new setting value take effect. This is due to the way the extension stores the settings configuration. When there were only a few settings, whose values would very rarely, if ever need to change, the extension cached them when it was loaded. Now that there are a bunch of settings that might be changed more often, it may make sense to re-evaluate this for an upcoming release.

Roadmap

The following tasks are scheduled for our upcoming sprint cycle(s):

1. Currently, the auto-update on save feature of this extension uses hard-coded strings to find and replace "modified by" name and "modified at" time & date. This means that if the user wants to change the template for the comment header, they would have to also edit the code or else break the extensions main feature! Clearly this is not ideal, and we hope to correct this flaw as soon as we can. Incidentally, this is why there is a warning below the template text boxes on the settings page, urging the user "do not modify!"
2. Some form of @copyright field would be useful, either directing the reader to a project-wide statement or file, or a URL, or else inserting a sting literal which would also be user defined via the settings page.
3. Comment headers often contain a version number along with the modified date & time. This would be implemented by way of an additional @Version field, with several formats to choose from in the settings. A selection of pre-configured version styles, along with a custom entry should the user wish to define their own.
4. File version numbers could be auto-incremented upon save. This would be enabled or disabled via a toggle from within the user (global) or workspace (project specific) settings. When enabled, the patch level of the version number would be incremented at the same time as modifying the modified at date & time.
5. Allow the user to specify rules as to how the version number is incremented. What defines whether to increment the patch number, or to increment the minor or major number?