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 _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
