On Thu, Oct 22, 2015 at 08:36:49AM +0300, Yedidyah Bar David wrote: > > > >> Makefile | 100 ++++++++++++++++++++++++++++++++++++ > > > > one adding the Makefile > > > >> automation/README.md | 8 +++ > >> automation/build-artifacts.packages | 10 ++++ > >> automation/build-artifacts.repos | 2 + > >> automation/build-artifacts.sh | 21 ++++++++ > >> automation/check-patch.packages | 10 ++++ > >> automation/check-patch.repos | 2 + > >> automation/check-patch.sh | 21 ++++++++ > > > > one adding the automation bits > > > >> ovirt-wgt-installer.spec | 63 +++++++++++++++++++++++ > > > > one adding the spec file > > > >> win-guest-tools.nsis | 31 +++++++---- > > > > and one adding the *VERSION variables > > Not sure about this one. > > I move here the maintenance of VERSION from the nsis file > to Makefile. > > If you really want to split them to two changes, I have to > carefully create a minimal Makefile just allowing this. > > I probably already did at one point, can check previous versions of > the change in gerrit. > > Is it really that important? I was thinking having first the version changes in the .nsis file, and then adding the Makefile. I think in this order you don't need a minimal Makefile (?). Having smaller/more focused commits will allow to have more specific commit logs :) With this commit as is, I don't know what is the reasoning for having variables for the installer/uninstaller names, nor how the 2 version numbers are meant to be used/what they mean (arbitrary user-visible version number for the built installer, version of the installer code, ...). Christopheh
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel