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

Martin Kletzander mkletzan at redhat.com
Tue Apr 9 07:08:47 UTC 2013


On 04/08/2013 10:07 PM, Gene Czarcinski wrote:
> v5.1 and v5.2 fixup for autobuild.sh NOT running under git.
> 

Same as subject, this would end up in the commit message.

> 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 it deleted.  If the version

s/it it/it is/

> 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).
> 
> The internal version id adds information from git-describe
> to the external version id.
> 
> Optionally, either the fixed version id of gconfig.__version__

You probably meant s/gconfig/cliconfig/ here.

> 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, then

s/the/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.
> 
> Note: Providsions to support autobuild.sh are included but

s/Providsions/Provisions/

> autobuild.sh is not updated.  This is/should/be addressed
> by a separate patch.
> 
> Note: sdist calls cliconfig.check_git() 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 such changes exist.
> 

s/such/if such/

> An alternate implementation would allow execution to continue
> but add ".dirty" to the version-id as an indicator
> that uncommitted changes existed.
> 

I don't think this is needed, as creating branches and stashes, etc. is
very fast in git, but OTOH I like the idea that it is seen how it was built.

> The virt-manager.spec file has been deleted and a
> virt-manager.spec.in file added so that @VERSION@ can be
> replaced with the external-version-id.
> 

Using 'git format-patch -M' or 'git mv virt-manager.spec{,.in}' would
make this patch a lot shorter and easier to go through as it would
detect the rename ;)

> Update .gitignore for new, non-managed files virtcli/version.pl

s/version\.pl/version.py/

> and virt-manager.spec
> .
> Signed-off-by: Gene Czarcinski <gene at czarc.net>
> ---
>  .gitignore           |   3 +
>  setup.py             |  21 +-
>  virt-manager         |   6 +-
>  virt-manager-tui     |   2 +-
>  virt-manager.spec    | 612 ---------------------------------------------------
>  virt-manager.spec.in | 612 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  virtcli/cliconfig.py | 127 ++++++++++-
>  virtinst/cli.py      |   2 +-
>  8 files changed, 764 insertions(+), 621 deletions(-)
>  delete mode 100644 virt-manager.spec
>  create mode 100644 virt-manager.spec.in
> 
> diff --git a/.gitignore b/.gitignore
> index e65afd5..8900707 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -3,6 +3,7 @@
>  *.gmo
>  
>  /.coverage
> +/dist

I'd add '/build' here as well.

Everything I tried after applying your patchset worked, so it looks good
to me.

Have a nice day,
Martin




More information about the virt-tools-list mailing list