Junio C Hamano <gitster@xxxxxxxxx> writes: > Ask Bjørn Hansen <ask@xxxxxxxxxxxxxx> writes: > ... >>> This is an alternative to my previous patch that just declared Perl >>> 5.8 to >>> be the required version. >> >> +1 to that one. > > Now, would somebody volunteer to go everywhere our user base (who no > longer read Release Notes) hang around, post a message saying that some > people on git development list are proposing to drop Perl 5.6 support, and > if the proposal goes ahead, it is possible that the next release may force > upgrading Perl for them, to make sure they won't complain saying they've > never heard about the "incompatible change" beforehand? Just in case before anybody overreacts without reading the mailing list backlog; the above is meant to be a moderately bitter joke ;-) I tend to think that everybody who needs to run git in their development environment (the deployment site could be running with ancient Perl for all we care --- after all, git or any SCM is primarily to be run in the development environment, and even if people use git to transfer the end result from the development side, all they need is the really core part of history tranfer tools like fetch, push and checkout on the deployed site; these tools do not depend on Perl) would be running 5.8 by now. Granted, some development machine need to have the exact same version of everything as the intended deployment environment for testing purposes, and some people may be developing a piece of software that is meant to run on Perl that is no more recent than 5.6, but with virtual machines and all, I think it would be rare to have such a setup --- it is a lot easier to develop on a platform with more reasonably recent Perl that your development tools (not limited to git itself) may depend on, and test on a virtual bochs with an ancient software configuration as the intended deployment site. So I personally think it is probably Ok to declare that we do depend on 5.8. -- 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
