Forums : Suggestions for Ohloh 2.0
Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.blackduck.com/s/black-duck-open-hub.
Beginning immediately, users can head over,
register,
get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.
On May 1, 2020, we will be freezing https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at
[email protected]
In some prominent place on the Ohloh ...
In some prominent place on the Ohloh site, please document the exact version of Ohcount currently in use, preferably in terms of a tag or git commit SHA1. Ideally, also document in each analysis record the version of Ohcount used for the analysis. This will help contributors to Ohcount know when their contributions begin to apply to Ohloh, and it will help monitor the status of features and bugs in the analyses.
Hi Josh,
Yes, there should be some way on the Ohloh web site to find out which revision of Ohcount is live on our servers. I'm not yet sure how this will happen technically, but I'll think on it. Perhaps we can put together some kind of status page that queries the live git repositories for a revision number.
Until something gets implemented, just assume we're using the master HEAD, because I'm probably not going to accept a patch and put it on git://labs.ohloh.net/git/ohcount.git master unless I intend to deploy it.
Regarding individual project analyses, it's unfortunately not that simple.
Ohloh reports are incremental -- when new commits are found, we append them to the existing report. This saves us the effort of recalculating the entire history of the project. The problem is that the version of the line counter can change between updates. So there is no single Ohcount version for an entire report.
It's conceivable that we could assign Ohcount version numbers to ranges of commits, but that's neither easy to store (there's currently nowhere in our database schema to stick this) nor easy to express on a web page.
Historically, Ohcount has been a very slow-moving piece of code. Typically, if we fix a major bug in a language or if we add a new language, we will do a full recount of all the affected projects. I can see how this might have to change in the future if Ohcount starts to change rapidly.
I guess this is all a long-winded way of saying, yes, I can see the value in this, but I can also see that this is hard to do right
. It needs some thought.
At the risk of expanding the conversation, there's another unresolved issue here as well: how we will increment the Ohcount version number? I slapped a 1.0.0 on our initial code base snapshot, but I've no idea how we'll proceed from there.
I think the SHA1 is the most accurate versioning tool, but it's not very user-friendly. It's impossible to tell which of two SHA1s represents an older version of the code, or whether a given SHA1 includes a particular fix. A nice integer revision number is the one Subversion convenience I miss here.
I didn't realize the incremental nature of the analyses; that does make this difficult. It would still help to know the current Ohcount version used for new analyses, though.
Meanwhile, how about somehow logging the Ohcount version in the project edits log, like the existing message showing an update of bestanalysisid?
For the Ohcount version number, try git-describe. If the current revision has a tag, git-describe will output that tag; otherwise, git-describe will output a version of the form tag-${NUMCOMMITSSINCETAG}-g${SHA1ABBREV}. (You can adjust the length of the abbreviated sha1 with the --abbrev option to git describe; you often want to use the full sha1.)
As for actually releasing a new version, the value of that varies. If you release on nearly every commit, that decreases the value of a release over pulling from the repo; if you release too infrequently, that will also decrease the value of a release over pulling from the repo. Ideally, a release should represent some increased level of stability due to testing, and pulling straight from version control trades some of that testing for freshness. If nobody tests the releases, and nobody goes to any extra effort to make releases more stable, then releases have no value, and you shouldn't bother making them. :)
If you do decide that releases have value, I'd suggest deciding on a convention for version numbers in advance. Something along the lines of x.y.z, where you increment z for bugfix-only releases, increment y for new features (such as new languages), and increment x for incompatible changes to the interfaces (meaning breakage in existing interfaces, not just the addition of new interfaces).