Version Tracking and Compatibility about cellblender

[GoogleCodeExporter]

One of the common "knocks" against GIT is the lack of a sequential version 
number. There are lots of forum discussions about this, and a variety of 
"fixes" that have been posted. In addition to the problem of not having a 
sequential version number, there's the problem of automatically putting 
whatever version number we DO use into the code so end users can identify it 
somewhere within Blender.

I've been browsing a bunch of sites, and I haven't found anything that really 
works well yet, but there's an approach worth mentioning at:

http://www.hermanradtke.com/blog/blog/canonical-version-numbers-with-git

That post suggests:

git describe –tags –long

This gives you a string like (in the case of one of my projects) 
2.1pre5-4-g675eae1 which is formatted as

{last reachable tag name}-{# of commits since that tag}-#{SHA of HEAD}

This gives you a ‘canonical version number’ that is monotonically 
increasing by commits, and unique across multiple repositories of development. 
If everyone is using the same HEAD, it will return the same value. If everyone 
uses the same most-recent-tag, but has different commits, the SHA will be 
different.

Here are the problems with this approach:

1. It is almost certain that without relying on the SHA we will have duplicate 
version numbers with this scheme whenever we have any untagged branches 
subsequent to a shared branch. In those cases, the parallel branches with the 
same number of revisions will share the same number.

2. We can't put the GIT SHA into the code because that will change the GIT SHA. 
But we can know the most-recent tag and the number of commits prior to the 
pending commit. So that information could be put into the code. That might be 
sufficient for most bug reporting needs.

So this is still an open issue.

Any ideas??

Original comment by [email protected] on 7 Feb 2013 at 11:32

[GoogleCodeExporter]

Tom and I talked about this issue, and we still don't have a solution that we 
really like.

However, in the interest of having SOMETHING that identifies which version of 
CellBlender we're running, I'm going to try write a simple function that 
generates an ID based on something like the SHA1 of the code files themselves. 
This will likely NOT be the SHA1 of the GIT commit because that SHA1 is based 
on more than just the code "blobs" (I believe the GIT SHA1 includes the GIT 
commit file and associated GIT tree as well as the blobs themselves). We might 
be able to generate the GIT SHA1 in the future, but that means we'd have to 
ship all that GIT data (or some representation of it) along with our AddOn. So 
for now, I'll just put together something that gives us a reasonable way of 
identifying what it is that's running inside Blender.

Original comment by [email protected] on 28 Mar 2013 at 11:00

[GoogleCodeExporter]

So far, I'm using a simple approach that just computes the sha1 of a list of 
hard-coded files. It seems to work, and it generates the same sha1 of the list 
whether run inside Blender or run as a standalone python program (which is 
good, because it gives us a way to calculate the "ID" for other purposes if 
needed).

My original plan was to have the registration function put this sha1 into the 
bl_info structure so it could be referenced everywhere. That works, except that 
I can't figure out how to reference the bl_info structure from other places 
(like cellblender_panels.py) where I need to display it. I tried stuffing it 
into scene.mcell, but that didn't seem to work during registration.

I had been thinking of the bl_info structure as a "global" location for such 
meta data, but maybe that's wrong. Does anyone have any suggestions on how to 
get data that I compute during registration into other sections of code (like 
cellblender_panels.py)?


By the way, here's the standalone version that computes the sha1 of the source 
files (this version uses a hard-coded ~/.config location where the actual code 
uses bpy....).


import os

bl_info = {
    "name": "CellBlender",
    "author": "Tom Bartol, Jacob Czech, Markus Dittrich, Bob Kuczewski",
    "version": (0, 1, 56),
    "blender": (2, 66, 1),
    "api": 55057,
    "location": "Properties > Scene > CellBlender Panel",
    "description": "CellBlender Modeling System for MCell",
    "warning": "",
    "wiki_url": "http://www.mcell.org",
    "tracker_url": "http://code.google.com/p/cellblender/issues/list",
    "category": "Cell Modeling",
    "supported_version_list": [(2, 64, 0), (2, 65, 0), (2, 66, 1)],
    "cellblender_source_list": [
        "__init__.py", 
        "cellblender_properties.py", 
        "cellblender_panels.py", 
        "cellblender_operators.py", 
        "io_mesh_mcell_mdl/__init__.py", 
        "io_mesh_mcell_mdl/export_mcell_mdl.py", 
        "io_mesh_mcell_mdl/import_mcell_mdl.py", 
        "io_mesh_mcell_mdl/mdlmesh_parser.py" ],
    "cellblender_source_sha1": "x"
}

import hashlib


cbsl = bl_info["cellblender_source_list"]
hashobject = hashlib.sha1()
for i in range(len(cbsl)):
    source_file_name = "~/.config/blender/2.66/scripts" + \
        os.sep + "addons" + os.sep + "cellblender" + os.sep + cbsl[i]
    print ( "Including SHA1 of ", source_file_name )
    hashobject.update ( open(source_file_name,'r').read().encode("utf-8") )
    print ( "  gives ... ", hashobject.hexdigest() )

bl_info['cellblender_source_sha1'] = hashobject.hexdigest()
print ( "CB Source Sha1 = ", bl_info['cellblender_source_sha1'] )

Original comment by [email protected] on 29 Mar 2013 at 2:08

[GoogleCodeExporter]

With lots of help from Jacob and Tom, I think our GIT Commit:

  7371fb20189ca858bd297abc089bdb9dd7f90a50

provides a workable solution to this issue (for now). This version computes the 
SHA1 of the list of source files found in the "bl_info" dictionary at the top 
of "__init__.py". So if we add any new files, they should be included in that 
list.

This version prints to standard out what it calls the "CellBlender Source ID" 
(useful for copying and pasting) and it also displays that same value in the 
"CellBlender Project Settings" panel within Blender. This version identifies 
itself as:

  a4891dfb864dec8c78f382e1ccf66e25946c3bfa

Unless there are any problems with this version, I believe it will satisfy the 
need to identify which version of the addon is being run. I suggest that this 
ability to identify a running version along with the "supported_version_list" 
(added previously) should be sufficient to consider this task completed for now.

Original comment by [email protected] on 5 Apr 2013 at 11:04

[GoogleCodeExporter]

Original comment by [email protected] on 5 Apr 2013 at 11:09

• Changed state: Fixed
• Added labels: Milestone-Release1.0