@ThosRTanner said in When is there going to be a release of NPP plugintemplate with a definition of NPPM_ADDSCNMODIFIEDFLAGS:
@rdipardo Wouldn’t a better place to put the action be in the notepad++ repo so when a new version was released it’d do the updates to the template repo automatically?
You make a good point.
The workflow steps would essentially be the same, but in the opposite direction (clone the template repo, update the file tree, validate the build and push if successful). The main difference would be the trigger; ideally you would want to watch for tagged Notepad++ releases, e.g.,
on:
push:
tags:
- 'v*'
This way new template versions can be explicitly tied to a Notepad++ release, e.g.,
# 'refs/tags/vX.Y.Z' -> 'vX.Y.Z'
echo "NPP_RELEASE=${env:GITHUB_REF}.Split('/')[2]" >> $env:GITHUB_ENV
# ...
git tag -a "${{ env.NPP_RELEASE }}" '@' -m "plugintemplate-for-Npp-${{ env.NPP_RELEASE}}"
git push --tags --repo=https://github.com/npp-plugins/plugintemplate
But it would be a problem if incompatible changes were made to the template. A failed build would cause a red X to appear beside the tagged Notepad++ commit, giving the false impression the release was a botch.
I think the separation of concerns principle is best observed if the template project looks after its own updates. A little extra churn won’t be a great inconvenience. The majority of plugin authors are still copy-pasting the template files into their source tree, as shown by how many have “C” as their detected primary language, since the template files contain no unique C++ syntax or standard headers, which GitHub relies on to classify header files, unless you manually override the heuristics.
