I've installed the new modular emoncms version on my Raspberry Pi in order to get familiar with it prior to upgrading my main instance.
In playing with it I've got a couple of questions...
1) What do we call it? We can't keep differentiating it by calling it "the new modular version"
2) In trying to problem solve issues going forward, we could do with a way of identifying what has been installed and what version it is.
I looked through the Raspberry PI module and couldn't see anything that leapt out to identify a version number.
My suggestion would be a page (under admin?) that lists the version number of Emoncms and the version numbers of each installed module. Has anyone else got any thoughts?
Re: Modular Emoncms and installed versions
I think that is a general problem with the whole of the software on this site. I suggested that there should be a proper version recording system to Trystan (I think) quite a while ago but it was not followed up.
I think as the very minimum each and every file should carry a clear version number and issue date.
So your proposal is wholeheartedly seconded here.
Re: Modular Emoncms and installed versions
I totally agree that a revision number would be a good thing to add. and really want to do a SHOUT OUT to Trystan to implement a decent changelog.md and second use the full possibilities of the git-tag command into the repository of emoncms on github.
---------------------------
The build number is useful for identifying which build you are on relative to some starting point. The combination of git-tag and git-describe provide a nice means of generating a build number that can be embedded into a build. git-describe can locate a specific previous tag with a glob pattern. The results of git describe will be formatted as:
tagname-[0-9]+-g[0-9a-f]+
Where the first pattern is the number of commits from the tag and the second pattern is the hash of the current commit. This can be nicely formatted into a build number. Including the hash (at least the first 7 characters) makes it simple to identify the specific commit associated with the build.
For example, git describe could return EmonCMS3-3.2-42-gd788e0e. This could be formatted to become EmonCMS-3.2 build 42 (d788e0e).
Example git project (https://github.com/mitchellh/vagrant/tags)
readmore on: http://git-scm.com/book/en/Git-Basics-Tagging and http://gitready.com/beginner/2009/02/03/tagging.html
scm/git/docs/git-tag.html) and
Re: Modular Emoncms and installed versions
Hello Robert, Alco Im happy to look at versioning but I need something really easy to work with, git tag looks good, if you could tell me the steps that would be good to follow to do this I will try and do it.
I often do a lot of really small commits, how does it work with that?
Re: Modular Emoncms and installed versions
I'm still struggling to get Git to do what I want it to, so I'm happy with anything that's (a) evidently sequential and (b) relatively clear. So on that basis EmonCMS3-3.2-42-gd788e0e fails (because the right-most part isn't sequential and not self-evident that it's a hash) but EmonCMS-3.2 build 42 passes. Am I right in thinking the hash is only relevant for assurance that two versions that produce the same hash are identical?
How will that apply to (say) SolarPV where you have several files - normal Git and all take the same version I presume?