Add Build Number to MisterHouse

[krkeegan]

The version number in "Mr. House Home" displays either a version number for the stable branch or unstable for the master branch.

Most people on the mailing list seem to be using Master. It is often hard to determine what version of code the user is running, making it difficult to diagnose issues. The git command line options would certainly tell the whole story, but users are not always command line friendly.

It would just be nice to have a simple display in the web interface that contains the build number for the user.

Solution

My thought is to create the build number by having MisterHouse call and parse the git describe command.

Right now that command displays something like:

insteon_from_cvs-878-g3a12b90

This is because the V3.0 tag was not created in the master branch. I think it would make the most sense if the tag were in the Master branch. In order to do this, I was thinking of merging in stable branch into master. There is one change in the readme.md file for some reason, and a change in the VERSION file. As a result, after this merge I will have to edit the VERSION file back to unstable.

The result will allow a build number such as:

v3.0 Build 298 (3a12b90)

If the git describe call failed, such as if the user manually installed MH, then some appropriate message would be displayed.

Thoughts/comments? Particularly on my plan to bring the v3.0 tag into master by merging in stable?

[hollie]

Hey Kevin,

I agree a reference would be handy. However: is there anything wrong with doing git rev-parse HEAD instead of doing 'git describe’? This returns the UID of the commit that is the current HEAD of the clone the user is using.

My idea of having a tag on stable is because it should do exactly that: point to a certain stable release. I don’t really understand what a merge of releases into master would bring us? The release branch is branched off master when we have a stable release. Merging those back into master will not help you IMHO.

I think that git describe is not the command we should use to see what version of master users are running. the rev-parse command does IMHO.

Kind regards,
Lieven.

Op 29-okt.-2013, om 23:29 heeft Kevin Robert Keegan [email protected] het volgende geschreven:

The version number in "Mr. House Home" displays either a version number for the stable branch or unstable for the master branch.

Most people on the mailing list seem to be using Master. It is often hard to determine what version of code the user is running, making it difficult to diagnose issues. The git command line options would certainly tell the whole story, but users are not always command line friendly.

It would just be nice to have a simple display in the web interface that contains the build number for the user.

Solution

My thought is to create the build number by having MisterHouse call and parse the git describe command.

Right now that command displays something like:

insteon_from_cvs-878-g3a12b90

This is because the V3.0 tag was not created in the master branch. I think it would make the most sense if the tag were in the Master branch. In order to do this, I was thinking of merging in stable branch into master. There is one change in the readme.md file for some reason, and a change in the VERSION file. As a result, after this merge I will have to edit the VERSION file back to unstable.

The result will allow a build number such as:

v3.0 Build 298 (3a12b90)

If the git describe call failed, such as if the user manually installed MH, then some appropriate message would be displayed.

Thoughts/comments? Particularly on my plan to bring the v3.0 tag into master by merging in stable?

—
Reply to this email directly or view it on GitHub.

[krkeegan]

Lieven,

I liked git describe because it gives a little more detail than git parse-rev HEAD does. The information returned by git describe looks like this: v3.0-298-gb8ba77d. This is a parsable format which contains the most recent tag v3.0 in this case. The number of commits since that tag 298 in this case. And the short hash of the current commit b8ba77d. The letter g is added to the start to make it distinguishable from the number of commits?? I dunno.

At the same time git parse-rev HEAD will return b8ba77d1beb7f3dc02353df81418773c39a42d76 which is the long hash of the current commit. Basically it returns the same but less information as git describe.

I think the number of commits since the tag is valuable information as it would allow me to quickly determine how recently an average user ran git pull without having to go and track down a hash. For example if I knew that in hollie/master the number of commits since the last tag was 298 and a user reports that he is on build 285, then I know that he is out of date. On the other hand, if a user simply reports the hash that they are on, and that hash is different, I have to track down the origin of that hash. Perhaps in the process of forking your branch, the user caused a merge to occur. Even though he has the correct build, it would not be immediately apparent.

I say average user because I realize this system would not work if someone went out and made a large number of commits on their own branch. But I don't envision this as a solution to solve their problems, I would think that this type of user would be more advanced with git and would be able to figure out the parent of his branch.

As to the merge question. My goal with the merge of stable into master is to import the v3.0 tag into master. The tag would still serve its purpose. In master it would point to the place at which stable is currently at. If there is another way to import the tag, and the pointer to the appropriate hash, without duplicating it, I am all ears. In the future, I would argue that the tagging should occur before the merge of master into stable so that this doesn't arise.

Kevin

[hollie]

Hey Kevin,

OK, I agree with you that (tag-commits-short ID) contains valuable information that helps in quickly finding out on what version a user is working on. You will however still need to check the commit ID to avoid that you assume a user is on a current version of master while in reality he has made some commits himself to the clone that cuase the ‚commits’ value to be equal to the number you expect it to be.

Why you want the tag to be equal to the last stable (v3.0) is not clear to me.

We can put a tag on master now (calling it devel’ orunstable’ or ) and then git describe would be unstable-xxx-gyyyyyyyy’. From then on we could based on the git describe output know the user is on ‚master’ due to theunstable’ tag and we could see how many commits since the tag the user clone is on and hence get an idea if the user is running a recent version of master or not.

I don’t agree that we should put new release tags on master. We want the tag to point to the stable release and not to a version of master that was used to create the release. The reason: the tags are automatically available as tgz files on github and we want those to point to the stable branch (IMHO).

In conclusion: I agree with the fact that we need a way to be able to see what version a user is working on. We should base this as you suggest on the info git provides (in that sense the VERSION file I added some time ago in the repo should be removed and we should use the output of ‚git descibe’ instead). But I think that if we want to do that we should ensure master has its own tag and this tag should be different from the stable releases ones. IMHO ‚merging a tag’ is not something that can be done. A tag is a pointer to a release. Merging code that was tagged into master will not cause the master branch to inherit the tag.

Best regards,
Lieven.

Op 30-okt.-2013, om 00:15 heeft Kevin Robert Keegan [email protected] het volgende geschreven:

Lieven,

I liked git describe because it gives a little more detail than git parse-rev HEAD does. The information returned by git describe looks like this: v3.0-298-gb8ba77d. This is a parsable format which contains the most recent tag v3.0 in this case. The number of commits since that tag 298 in this case. And the short hash of the current commit b8ba77d. The letter g is added to the start to make it distinguishable from the number of commits?? I dunno.

At the same time git parse-rev HEAD will return b8ba77d which is the long hash of the current commit. Basically it returns the same but less information as git describe.

I think the number of commits since the tag is valuable information as it would allow me to quickly determine how recently an average user ran git pull without having to go and track down a hash. For example if I knew that in hollie/master the number of commits since the last tag was 298 and a user reports that he is on build 285, then I know that he is out of date. On the other hand, if a user simply reports the hash that they are on, and that hash is different, I have to track down the origin of that hash. Perhaps in the process of forking your branch, the user caused a merge to occur. Even though he has the correct build, it would not be immediately apparent.

I say average user because I realize this system would not work if someone went out and made a large number of commits on their own branch. But I don't envision this as a solution to solve their problems, I would think that this type of user would be more advanced with git and would be able to figure out the parent of his branch.

As to the merge question. My goal with the merge of stable into master is to import the v3.0 tag into master. The tag would still serve its purpose. In master it would point to the place at which stable is currently at. If there is another way to import the tag, and the pointer to the appropriate hash, without duplicating it, I am all ears. In the future, I would argue that the tagging should occur before the merge of master into stable so that this doesn't arise.

Kevin

—
Reply to this email directly or view it on GitHub.

[krkeegan]

Lieven,

Fair point, any tag would likely do.

I also see your point regarding having the version tags be the final release so that they can be downloadable in github.

So then the question is, what should the unstable tag be? Should master just be tagged once, or should it be repeatedly tagged at some interval?

I would like to tag the unstable branch every time we merge it into stable to create a release. My reason for having a serial tagging process rather than just tagging the branch once is to catch up those users who fork out from master. For example, if a user forks master today and does 100 commits, as noted, the build number becomes useless. But if that user later merges master back in the next time we do a stable release, his build number will be reset to 0 just like the rest of us. If the user no longer does any more commits, we will all be back on the same page. I concede that this could be good or bad, but I think on the whole it would be good.

Kevin

[krkeegan]

Similarly, any idea for how to handle the Version Date listed as Modified on the about page? Right now it uses the modification date of the main mh script. This tells us something, but is probably rather misleading for most users.

Is there a better way to do this?

For stable, it should probably just check the modification date of the VERSION file.

For unstable, should we use a git command again to find the last commit date?

Those running unstable who have not obtained MH from git are at a significant disadvantage.

[hollie]

Kevin,

what to do with the people who download a stable zipfile and don’t have git installed on their system? Do we keep the VERSION file in the stable releases and fallback to git when we see that we’re running the master branch? What to do with people who download the master branch zipfile and who don’t have git installed?

Kind regards,
Lieven.

Op 30-okt.-2013, om 19:36 heeft Kevin Robert Keegan [email protected] het volgende geschreven:

Lieven,

Fair point, any tag would likely do.

I also see your point regarding having the version tags be the final release so that they can be downloadable in github.

So then the question is, what should the unstable tag be? Should master just be tagged once, or should it be repeatedly tagged at some interval?

I would like to tag the unstable branch every time we merge it into stable to create a release. My reason for having a serial tagging process rather than just tagging the branch once is to catch up those users who fork out from master. For example, if a user forks master today and does 100 commits, as noted, the build number becomes useless. But if that user later merges master back in the next time we do a stable release, his build number will be reset to 0 just like the rest of us. If the user no longer does any more commits, we will all be back on the same page. I concede that this could be good or bad, but I think on the whole it would be good.

Kevin

—
Reply to this email directly or view it on GitHub.

[krkeegan]

Lieven,

Yes, the VERSION file will continue to exist as it does today. The only changes will be within the bin/mh script and are fairly simple. I will push the changes later tonight once I revive my crashed computer.

For Version information:

• If VERSION != unstable: then the version number is displayed.
• If VERSION == unstable && git command returns valid response: then display git describe information.
• If VERSION == unstable && git command doesn't work: then display contents of VERSION.

For Modified Date:

• If VERSION != unstable: then display modification date of VERSION file.
• If VERSION == unstable && git command returns valid response: then display git show date of last commit.
• If VERSION == unstable && git command doesn't work: then display modification date of VERSION file.

I also decided that a single unstable tag will be sufficient, ie no need to continuously add tags to the master branch.

Kevin

[hollie]

Hey Kevin,

VERSION file/modified date: I agree with your proposal.

Single tag: I agree too.

Best regards,
Lieven.

Op 5-nov.-2013, om 02:10 heeft Kevin Robert Keegan [email protected] het volgende geschreven:

Lieven,

Yes, the VERSION file will continue to exist as it does today. The only changes will be within the bin/mh script and are fairly simple. I will push the changes later tonight once I revive my crashed computer.

For Version information:

• If VERSION != unstable: then the version number is displayed.

• If VERSION == unstable && git command returns valid response: then display git describe information.

• If VERSION == unstable && git command doesn't work: then display contents of VERSION.

For Modified Date:

• If VERSION != unstable: then display modification date of VERSION file.

• If VERSION == unstable && git command returns valid response: then display git show date of last commit.

• If VERSION == unstable && git command doesn't work: then display modification date of VERSION file.

I also decided that a single unstable tag will be sufficient, ie no need to continuously add tags to the master branch.

Kevin

—
Reply to this email directly or view it on GitHub.

[krkeegan]

This was merged in #304