release-candidate-v0.2.5

Release candidate v0.2.5.

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

v0.2.5 Release notes

**Release date 2022-11-15

• Fixed issue where last Modified By name could be undefined

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?

release-candidate-v0.2.4

Release candidate v0.2.4.

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

v0.2.4 Release notes

**Release date 2022-11-15

• Emergency bug fix to restore extension functionality. This extension had no dependancies prior to v0.2.3. In this release, a dependancy had been added to the project but node_modules was being deliberately excluded from the published package via the vscodeignore file.
  Removed old versions of this change log - to view old releases prior to v0.2.0 please refer to the github repository

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?

release-candidate-v0.2.3

Release candidate v0.2.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.2.1
4. Release diectly to Marketplace with vsce publish

v0.2.3 Release notes

** Release date 2022-11-15

• When inserting a header into a file using the keyboartd shortcut, (CTRL+ALT+I by default) a new input dialog box is now displayed that prompts for a description of the file. This change does not apply to existing headers, and the dialog is not shown if the @description field is turned off.
  ** Escaping this dialog or entering a blank value will cause the default value to be rendered.
• Modified the header pre-processing function so that rendering options are now processed programmatically instead of having to manually update this function every time we add a new rendering option. This doesn't change the user experience but should hopefully speed up future development when adding new rendering features as there will be less changes to make and therefore less code to test and potentially break.

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?

release-candidate-v0.2.2

Release candidate v0.2.2.

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.2 Release notes

** Release date 2022-11-13**
This release contains fixes for issue #7 issue #6 and issue #4

Notable changes include:

• Removed trailing C-style closing comment from the HTML template.
• Added validation to the configuration settings for the email address and date format text boxes. Invalid entries will display an error message informing the user and this invalid setting will not be updated until corrected.
• Corrected the inconsistent formatting for the File Types information label beneath the templates. They should now all look the same.
• Fixed issue whereby changes to the extension settings were not being used until vscode was rebooted. This was due to the extension caching the settings when it is first loaded, so changes to the settings weren't being used until next reload.

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?

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?

release-candidate-v0.2.0

Release candidate v0.2.0

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

v0.2.0 Release notes

Release date 2022-10-18

Incremented the minor version to reflect the new functionality. V0.2 of the extension should be the last development cycle before the extension is production ready - that is, officially released as v1.x.y! Some of the changes going into this initial 0.2 release are:

• As promised, the new date format string added to the settings in the previous release now defines the date & time format for the file comment header. This string uses the allowed formatting for a javascript Date object, such as yyyy-MM-dd for a date that looks like 2022-12-03
• Unit tests have been added for all fileheader module functions, which will assist future development not to break things.

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?

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?

release-candidate-v0.1.3

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

v0.1.3 Release notes

Release date 2022-10-16

Change log (v0.1.3)

• Re-factored the way the templates are displayed by the Settings UI so that they are grouped together and categorised by language type.
• Added logic to use the user-defined Author name when the Modified By remains undefined (either when it remains the defualt value or is blank).
• Updated the Settings UI description fields so that markdown tags now work.

The extension is now called file-header-comments, since the previous name was (obviously!) in use. The presumption that an extension was uniquely identified by a the combination of publisherId.extensionName was wrong, and the extension name has to also be unique. However, the settings are keeping the fileheader prefix, so that if a user upgrades to this extension, their settings will transfer automatically.

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?

release-candidate-v0.1.1

Release candidate v0.1.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.1.1

v0.1.1 Release notes

Release date 2022-10-16

Change log (v0.1.1)

1. Re-worded the displayName field in the package manifest, since it was the same as the name field, we were giving up on the opportunity to explain what our extension does to those marketplace browsers who might only quickly scan down the list of extensions. It didn't make sense to have the same name twice, especially when said name is not very explanatory.
2. Fixed the sponsor URL in the manifest.
3. Removed the README for ch-zn (simplified chinese) which is now out of date and we lack the ability to make the required translations to bring it up to date. It is preferable to have an English only README and let the users browser translate it for them than provide a README that is wrong.

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?

release-candidate-v0.1.0

Release candidate v0.1.0.

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.0

New publisher!

Note on this release: There has been no release of the original author's extension in six years; this is despite changes being made and committed to the repository three years ago. Given this lack of activity, the unreleased modifications and further improvements to be made, CodingQ has assumed responsibility for its continuing development under the assumption that the original author has abandoned the extension.

v0.1.0 Release notes

Release date 2022-10-15

This release candidate has been prepared under a new publisher. This effectively means that it becomes a whole new vscode maketplace extension with a new history. Sadly this means that users of the existing extension will not be upgraded automatically. Attempts to contact the original author are ongoing, in the hope that either we can a) merge the new functionality into the parent repository, b) have the ability to modify the existing extension, or else c) have it transferred under our control. Failing any of those options, we hope the previous author could at least mark the old extension as deprecated and direct users to install this new one.

Change log (v0.1.0)

Main changes: File comment headers for most common file types are now supported. Each type has its own the template that can be found in the settings. The look is identical to the C-Style comment block, but using the alternative comment character instead of an asterisk (*). See below for details.

Two additional fields have been added into the comment header, @Email and @description. The author email can be adjusted in the settings in the same way as the author name, whilst the description tag can be edited to provide a description of the file after the comment header is inserted.

Additional changes: Several bug fixes have been applied to the parent repository in the six years since the last release of the extension. This release contains these fixes.

Added support for languages and scripts that use alternative characters for comments:

1. Shell scripts and other scripting languages, such as perl and python, use hash (#) comments.
2. Visual basic uses apostrophe (') for comments.
3. html comment blocks uses a string of exclamation mark and dashes inside angled brackets.

These three additional comment types means that comment headers can be added to all of the popular development languages. Should you find that your preferred language has been missed out, raise an issue and we will implement your request straight away!

Roadmap

With the release of this new extension, the following changes are planned for the next sprint cycle:

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?