On Mon, Jul 14, 2008 at 12:00:54PM -0700, Junio C Hamano wrote: > But as the upstream, we have our own deprecation schedule. We should of > course plan carefully not to harm existing users of our releases, but > frankly speaking, 18 months since 1.4.4.4 was tagged (early January 2007) > is an eternity in git timescale. Maybe we will slow down someday, and > this 18-month is not a set-in-stone rule in any way, but at this point > even without the packfile format issues, I personally think anything > before 1.5.0 is irrelevant --- maybe they are interesting as historical > curiosities, but not more than that. Really, I think this is should be put into certain perspective: (i) This change is special since it affects client-server compatibility in bare repositories. AFAIK, none of the others you mention does this. (ii) The CRC checking is perhaps quite an improvement, but I don't think it is critical-to-have-just-now. (iii) Most importantly, this is not about waiting another few years for Debian to catch up, since the next stable release should really be upcoming rather soon: http://debian-community.org/LennyReleaseSchedule/ (iv) These problems do not concern people who are currently _actively_ _working_ with Git; these people hopefully do not use 1.4 willingly and already use Git from backports.org. This is about user experience for casual users who are quite possibly interested only in read-only tracking of upstream using Git - these people will likely use default Debian Git version and that is okay, because frankly, for them, the 1.5 improvements do not really matter much. This is also large class of prospective future real Git users and we might not want to ruin Git's reputation in their eyes. -- Petr "Pasky" Baudis GNU, n. An animal of South Africa, which in its domesticated state resembles a horse, a buffalo and a stag. In its wild condition it is something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce -- 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
