On Sun, Apr 02, 2017 at 08:05:01AM -0400, Dan wrote:
Hi All, To compile to a non-current version, I could download a tar ball, or switch to an older branch in git, then do ./autogen.sh (or ./configure) && make && make install. But for some purpose, I may want to compile to historical version easily without redundantly downloading the source by using some magic flag passed into either ./configure, ./autogen.sh, or make, e.g.: $ ./configure --version=2.0, or $ ./autogen.sh --version-git=1.0 Is that possible at all?
I haven't heard of any project ever that would do anything like this. Is it that much more complicated to do: git checkout v2.0.0; git clean -fxd; git submodule update In most cases only the first command needs to be done anyway.
Related question, normally speaking, how to test back-compatibility of a new patch, or do we need to test it at all?
Depends what you want to test. For some things it's enough to have a rule, for example that you must not change API call numbers. For others there are tests. If tests start failing, something went wrong. If you have pdwtags installed, usually from the 'dwarves' package, there is also test for remote structures (that they don't change), but mostly people need to be careful while writing and reviewing code.
P.S., I was just reading v0.0.1 libvirt [1].
Funny fact, back then it was libvir! not libvirt. Hence the mailing list address.
It is so nice to see there is, well, was nothing more then 2000 LOC for C source code.
Well it also didn't do much, I presume. I can't say for sure, though, I'm just guessing it from the documentation. Isn't this how all projects start? =)
[1] ftp://libvirt.org/libvirt/old/libvir-0.0.1.tar.gz Dan
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
