> > * One option on the Travis front would be to just test one combination > > of the 1.1 build - e.g. linux + clang + 1.1, so you'll stay within the > > 5 parallel builds while also having some coverage on lfs 1.1. > TBH I still think testing an outdated Git LFS version does not justify > +10 extra minutes of computing. I agree that checking compatibility with an older Git LFS version doesn't worth the extra 10 minutes. However, since Git LFS is only involved in two test scripts and for the rest of the test suite it doesn't matter at all, doing a full build and running the whole test suite for the sole sake of a different Git LFS version is definitely unnecessary. The Bash completion and prompt scripts are in a similar situation: there are only two test scripts involved and the rest of the test suite couldn't care less. However, we definitely want to support older Bash versions as well, all the way back to v3.0, and there are a few commits fixing breakages reported by users of old Bash versions. As I somehow grew fond of those Bash scripts over the years, I put together a couple of patches allowing me to say 'cd t && make -j4 full-bash-test', which runs the completion and prompt tests with multiple Bash versions. For the seven major and minor releases including and after v3.0 it usually takes less than 8 seconds. As far as runtime goes, I think that's well worth it. You can have a look at these patches at https://github.com/szeder/git completion-test-multiple-bash-versions and perhaps you could even adapt it to LFS and/or p4 somehow. > Plus if we want to be consistent we would > need to do the same for LFS 1.0, 1.2, and for pretty much every other > dependency... I'm not sure we should be consistent in this case, at least not solely for consistency's sake and not in git.git. Taking what I did for Bash and doing it for different versions of LFS, p4, etc. could perhaps keep the runtime under control, but t/Makefile would surely get out of control rather quickly. Putting these into a travis-ci matrix is so much simpler, but the runtime makes it infeasible, of course. I think the best we can do is to keep this out of git.git and let (hope?) developers interested in a particular subsystem do this "multiple version compatibility" tests as they see fit. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html