[virt-tools-list] [PATCH-v5.5 5/5] virt-manager version-id changes

[Cole Robinson]

On 04/09/2013 03:19 PM, Gene Czarcinski wrote:
> The current situation where a fixed value only is used
> for the version of the virt-manager tarball is not
> acceptable if for no other reason than it does not
> reflect just what is in the tarball.
> 
> This update changes the virt-manager version id and
> introduces an *external* version id used for the sdist tarball
> and an *internal* version id which is displayed by
> ./virt-manager --version
> 
> The external version id is based on either cliconfig.__version__
> or the result of git-describe--tags.  If the version
> includes the prefix "RELEASE-", it is deleted.  If the version
> includes any suffix it is deleted but noted that it is
> present.  If there is a suffix or git-describe returns values for the number of
> commits and current commit id, then the external version id
> includes '.gityyyymmdd' as a suffix (e.g., '.git20130403').
> 
> Note: If more granulariy is needed to differentiate
> snapshots, tags can be added/used to provide such
> granularity.  E.g., instead of 0.9.5, have 0,9.5.100.
> 
> The internal version id adds information from git-describe
> to the external version id.
> 
> Optionally, either the fixed version id of cliconfig.__version__
> or a version id based on the tag portion of git-describe
> is used.  This is specified as 'tag' or 'fixed' for
> __vertype__ in virtcli/version.py.
> 
> get_version_1() returns the external-version-id and
> get_version_2() returns the internal-version-id.
> 
> If the versioning code is run in the git-clone repository,
> the the version ids are initializated.  If not running under
> git, then version.__version_1__ [external] and
> version__version_2__ [internal] are used.  These were
> created the last time sdist was run and are stored
> in virtcli/version.py.
> 
> There are provisions for autobuild so that when autobuild.sh
> is run, AUTOBUILD_OVERRIDE_VERSION=y causes the suffix to
> be ignored so that the autobuild naming is in effect for
> rpms.
> 
> Note: Provisions to support autobuild.sh are included but
> autobuild.sh is not updated.  This is/should/be addressed
> by a separate patch.
> 
> Note: sdist calls cliconfig.check_git_uncommited_changes()
> to verify that there are no uncommitted changes.  If, and
> only if running this is a git repository, a check is made
> for uncommitted changes and execution is aborted if such
> changes exist.
> 
> The virt-manager.spec file has been renamed virt-manager.spec.in
> and the release-id changed to @VERSION@ so that it can be
> replaced with the external-version-id when setup-sdist is run.
> 
> Update .gitignore for new, non-managed files virtcli/version.py
> and virt-manager.spec
> .

Gene, I'm sorry, but I truly have no interest in maintaining this as part of
virt-manager. The problems you describe affect just about every open source
project I've worked on, so even though it _is_ sub optimal it's common enough
that it clearly doesn't cause too much grief, so it doesn't warrant such a
complex solution.

This code also has numerous problems:

- _check_for_git is run on every invocation of virt-manager, even a system
installed one.
- this will give incorrect results if /usr/bin/virt-manager is run from a
completely unrelated git repo
- this non-standard behavior isn't documented anywhere
- uses deprecated 'commands' module
- stylistic problems: _init_version is a 40 line function with no line breaks,
get_version_1/2 are unclear function names, long lines, few comments, etc.

If what you want is to do regular builds of virt-manager which have a fully
descriptive git tag in the virt-manager --version and RPM version, my
recommendation is to just come up with a private script that edits __version__
and kicks off a build. Or maybe add a setup.py switch to configure/build/rpm
or similar that takes a manually specified version and does the magic. I'm
willing to entertain other simple, non-invasive ideas. But generating a unique
version from git calls in python code as part of virt-manager is just overkill.

- Cole