release-candidate-v0.1.4

Release candidate v0.1.3.

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.1.4
4. Release diectly to Marketplace with vsce publish

v0.1.4 Release notes

Release date 2022-10-18

Change log (v0.1.4)

The bulk of this change implements unit testing of the file header comments logic; this required refactoring the extensions entry points and undoing some nasty close-coupling. Worth it, but users won't see a great deal of change with this release. Going forward, it should facilitate quicker development, since unit tests can now be ran.

• Re-factored extension logic, separating the file header comments engine and related manipulation/population of headers out of extension.js and into a separate module. This additional layer of abstraction undoes some of the close-coupled functionality of extension.js and facilitates unit testing of the header logic.
  Extension.js couldn't be unit tested under the mocha framework as vscode is an invalid reference (by design; modules referencing vscode can only be integration tested, according to mocha documentation).
• Modified extension's keywords to make searching for the extension in the marketplace a little easier (and attempting to link it to the previous extension name).
• Added a new setting for the date format to the configuration properties. Users can now modify the display format string via the settings UI. This string is not currently referenced within the code, and the format string is currently hard-coded within the extension, but this will be usable from the next release of the extension!

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?