I agree a (min) 2 branch strategy is needed for all the (emoncms family?) repos for “released” and “development” versions. I also think the branch naming should be uniform accross all the repos so that once we start to implement some form of version checking/automated updates, the branch can be set just the once rather than having to somehow accommodate a separate branch ref for each module, so that you are effectively running a whole “released” setup (default) or a complete “development” setup (advanced or devs only etc) possibly even able to switch between them.
The simpler the file is the easier it is to parse, easier to parse means less complexity, less errors and better reliability.
Ideally a simple “version” file is ideal, but to avoid maintaining 2 files I thought one file might be better, no syncing required as just one place to edit.
However, IMO there absolutely must be a file with the version easily accessible in-side the emoncms repo/folder for emoncms to have both a local(current) and on-line(latest) version to compare.
The changelog is currently being discussed as being 1) on the forum, 2) within the released “tag” notes on emoncms and also 3) within the code in the form of a changelog.md (AND possibly even on gitprint), so I question the need for an actual changelog.md file since users can view the changelog in other places, I think a “version” file is more appropriate and if we choose it can also contain some changelog, if we choose to only have the version number in the first line for easy parsing, the content and format of rest of the file can be unimportant.
But if the file did remain empty apart from the version number it would be even easier to parse, the following url would act like a proper api call
https://raw.githubusercontent.com/emoncms/<MODULE>/<BRANCH>/version
so perhaps if we must have a changelog 2 files is better than 1?
I looked into that too, and yes “messy” is a good word for it!
The more i think about it I think a choice between an in repo changelog and “tag notes” is required and just “officially” maintain the one changelog, and if one of us then decide to make an announcement on the forum that a new version has been tagged (and cut&paste the changelog text from the repo to the forum), I’m sure T&G are not going to forbid us from doing that!
Using a “closed to comments” thread that all emoncms users can subscribe to will enable users to easily stay up to date and encourage users to visit the forum following each release rather than just when things go wrong.
On that note I wonder if a main announcements category is preferable with an “emoncms-announcements” sub-category for all the emoncms repos announcement threads to reside in, that way a user can subscribe to all emoncms-announcements by subscribing to the category rather than all the individual threads. Or even to the main announcements category to include other softwares such as emonhub or emonpi in time.
As a side note, I think the naming used by emoncms/emoncms is not clear when the master branch is called “stable” and the development branch is called “master”, this conflicts with normal GitHub usage, so I would question whether those same names should be rolled out to all the other repos or if implementing this would be the ideal time to change the names on the one repo. It would not be difficult to allow a static “stable” branch to remain for a while until all users have updated, and just the emonpi script can be adjusted, once updated the branch name would be set within emoncms.
