{"thread":{"id":"29523","subject":"how to determine oldest supported version of git","startedAt":"2012-02-02T16:46:11Z","lastAt":"2012-02-15T18:44:08Z","messageCount":11,"participants":["Neal Kreitzinger","Jonathan Nieder","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"183615","messageId":"jgeekn$of2$1@dough.gmane.org","threadId":"29523","inReplyTo":null,"subject":"how to determine oldest supported version of git","fromName":"Neal Kreitzinger","fromEmail":"neal@rsss.com","sentAt":"2012-02-02T16:46:11Z","receivedAt":"2012-02-02T16:46:11Z","isPatch":false,"sender":{"key":"neal@rsss.com","avatar":null},"body":"What is the best way for me (a git user) to determine what is currently the \noldest supported version of git (the oldest version still getting bugfixes)? \nIOW, when can I tell that my version of git is no longer supported?\n\nv/r,\nneal \n"},{"id":"183636","messageId":"20120202192124.GA19873@burratino","threadId":"29523","inReplyTo":"jgeekn$of2$1@dough.gmane.org","subject":"Re: how to determine oldest supported version of git","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-02-02T19:23:40Z","receivedAt":"2012-02-02T19:23:40Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Neal,\n\nNeal Kreitzinger wrote:\n\n> What is the best way for me (a git user) to determine what is currently the \n> oldest supported version of git (the oldest version still getting bugfixes)? \n> IOW, when can I tell that my version of git is no longer supported?\n\nIt depends what supported means.  Even very old git releases might get\npoint updates to fix major problems such as security bugs.\n\nIf you want to see which branches Junio is actively maintaining,\nlooking at the last commit date from the maint-* branches on [1] is\none way.\n\nHowever, in my experience people interested in product lifetimes more\noften mean \"versions the vendor will respond to bug reports about\"\nrather than \"versions getting updates\".  If you have discovered a bug\nin an old version of git, even if it is only a couple of major\nreleases ago, a good debugging strategy is almost always to try with\nthe newest release and see if it still exhibits the bug.  If you don't\ntry that, people on this list might just try it themselves.  If it\ndoesn't affect recent releases, I would not be surprised if people on\nthis list do not necessarily care much.  One can more easily interest\nme at least by pointing out which regression is making it hard to\nupgrade instead.\n\nThanks,\nJonathan\n\n[1] git://github.com/gitster/git.git\n"},{"id":"183643","messageId":"20120202194937.GB9246@sigill.intra.peff.net","threadId":"29523","inReplyTo":"20120202192124.GA19873@burratino","subject":"Re: how to determine oldest supported version of git","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-02T19:49:37Z","receivedAt":"2012-02-02T19:49:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 02, 2012 at 01:23:40PM -0600, Jonathan Nieder wrote:\n\n> However, in my experience people interested in product lifetimes more\n> often mean \"versions the vendor will respond to bug reports about\"\n> rather than \"versions getting updates\".  If you have discovered a bug\n> in an old version of git, even if it is only a couple of major\n> releases ago, a good debugging strategy is almost always to try with\n> the newest release and see if it still exhibits the bug.  If you don't\n> try that, people on this list might just try it themselves.  If it\n> doesn't affect recent releases, I would not be surprised if people on\n> this list do not necessarily care much.  One can more easily interest\n> me at least by pointing out which regression is making it hard to\n> upgrade instead.\n\nAgreed. It is very annoying to have somebody report a bug, I (or another\ndev) spends time trying to reproduce, and then we find out that it was\nactually fixed a year ago.\n\nHowever, I am much happier if a submitter does that leg-work themselves,\nand posts to the list something like:\n\n  I am using version a.b.c. It has bug $FOO, which was fixed by $COMMIT\n  and released in d.e.f [or even \"I tried d.e.f and it does not exhibit\n  the bug\"]. This bug fix should get cherry-picked back to a.b.c,\n  because {it is more important than usual for reason X, upgrading past\n  a.b.c is not feasible for reason Y, etc}.\n\nNobody wastes time tracking down the already-fixed bug, and it's\nrelatively easy to decide whether the cherry-pick is worth the effort\nbased on the reasoning given.\n\nI know not everybody is capable of complex bisection or writing a\nsuccinct test case. But they can at least try to reproduce with the\nlatest version and convert \"there's a bug in git\" to \"there's a bug in\nthis old version of git\".\n\n-Peff\n"},{"id":"183694","messageId":"7v8vkktt6y.fsf@alter.siamese.dyndns.org","threadId":"29523","inReplyTo":"jgeekn$of2$1@dough.gmane.org","subject":"Re: how to determine oldest supported version of git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-03T04:52:05Z","receivedAt":"2012-02-03T04:52:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Neal Kreitzinger\" <neal@rsss.com> writes:\n\n> What is the best way for me (a git user) to determine what is currently\n> the oldest supported version of git (the oldest version still getting\n> bugfixes)?  IOW, when can I tell that my version of git is no longer\n> supported?\n\n\"A note from the maintainer\" only promises that the latest major release\n(as of this writing, 1.7.9) gets regular maintenance releases until the\nnext major release happens.\n\nWhen queuing a fix to an old bug, however, I try to build a topic branch\nfor that fix from as old an release as practical, in order to make sure\nthat older maintenance tracks could benefit, and I do give updates for\nolder maintenance tracks when able (but no promises).\n\nFor example, during the last cycle leading to 1.7.9, in other words, back\nwhen 1.7.8 was the latest major release, in addition to the maintenance\nreleases 1.7.8.1, 1.7.8.2, 1.7.8.3 and 1.7.8.4, maintenance releases for\nolder version of Git were tagged (1.7.6.5, 1.7.7.5, and 1.7.7.6).  Note\nthat 1.7.6 was originally released on June 26th, 2011.\n\nOne cycle of major release development is expected to last between 8 to 10\nweeks, so keeping two stale maintenance tracks in addition to the latest\nmaintenance track alive would roughly translate to 6 months shelf life for\nan ancient release.\n\nAs other people mentioned, if you are on a (probably paid) support plan\nfrom a(n enterprise) distro, asking them would be the best way, and if you\nare running Git supplied as part of a distro, the distro would dictate the\nversion it supplies to you, so asking here would not help very much.\n"},{"id":"183754","messageId":"4F2C415D.4000309@gmail.com","threadId":"29523","inReplyTo":"7v8vkktt6y.fsf@alter.siamese.dyndns.org","subject":"Re: how to determine oldest supported version of git","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2012-02-03T20:19:41Z","receivedAt":"2012-02-03T20:19:41Z","isPatch":false,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"On 2/2/2012 10:52 PM, Junio C Hamano wrote:\n> As other people mentioned, if you are on a (probably paid) support plan\n> from a(n enterprise) distro, asking them would be the best way, and if you\n> are running Git supplied as part of a distro, the distro would dictate the\n> version it supplies to you, so asking here would not help very much.\nWe compile our git from you (and your cohort).  (Our paid distro does \nnot keep up.)  Your replies have been *very* helpful.\n\nthanks!\n\nv/r,\nneal\n"},{"id":"184381","messageId":"7vwr7upj9m.fsf@alter.siamese.dyndns.org","threadId":"29523","inReplyTo":"7v8vkktt6y.fsf@alter.siamese.dyndns.org","subject":"Re: how to determine oldest supported version of git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-10T19:42:45Z","receivedAt":"2012-02-10T19:42:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> \"Neal Kreitzinger\" <neal@rsss.com> writes:\n>\n>> What is the best way for me (a git user) to determine what is currently\n>> the oldest supported version of git (the oldest version still getting\n>> bugfixes)?  IOW, when can I tell that my version of git is no longer\n>> supported?\n>\n> \"A note from the maintainer\" only promises that the latest major release\n> (as of this writing, 1.7.9) gets regular maintenance releases until the\n> next major release happens.\n>\n> When queuing a fix to an old bug, however, I try to build a topic branch\n> for that fix from as old an release as practical, in order to make sure\n> that older maintenance tracks could benefit, and I do give updates for\n> older maintenance tracks when able (but no promises).\n> ...\n> One cycle of major release development is expected to last between 8 to 10\n> weeks, so keeping two stale maintenance tracks in addition to the latest\n> maintenance track alive would roughly translate to 6 months shelf life for\n> an ancient release.\n\nHaving said all that, I am starting to doubt what the point of all\nthis is.\n\nMaybe I am being slow to come to this realization after having done this\nfor all these years, but Git is not like the Linux kernel, where hundreds\nof companies maintain their own internal forks, e.g. out of tree drivers,\nfilesystem tweaks or scheduler tweaks, all tied to a specific version of\nthe internal API that is a rapidly moving target and cannot afford to\nadjust to the bleeding edge.  Also our strict no regression policy means\nthat it is not like an option --foo in one version of Git changes its\nmeaning from X to Y across version boundaries, and even if on rare\noccasions we need to introduce incompatibilities to improve the system, we\ngive enough advance warning and execute careful migration plans to ensure\nthat third-parties can keep up, and the \"fix at the oldest branch and\nmerge upwards\" policy means fixes to important bugs will be in all the\nmaintenance tracks, including the 'master' version.\n\nSo in practical terms, once 1.7.9 is out, there is *no* practical reason\nfor anybody to use 1.7.8.x or anything older. The only two things people\nare gaining by sticking to an older version are that (1) they do not have\na way to use new features, and that (2) they get fixes that are less\nrigorously tested, because the testing happens mostly in the context of\nthe 'next' branch and then subsequently in the 'master' branch, and fixes\ncooked in these two contexts may have unintended consequences that will\nnever be discovered until they are merged down to the older maintenance\ntracks.\n\nIf we only released the feature releases without _any_ maintenance\nreleases, distros no longer have an excuse to stick to older maintenance\ntracks (\"For the upcoming Zesty Zebra LTS, Git will stay at 1.7.7.x and\nnever updated to any newer major version.\")  This in turn removes the need\nfor the third-party tools that support wider Git ecosystem to worry about\ntheir users who are kept on very stale versions of Git by distros, because\nany reasonably maintained distro will not pin their users to an ancient\nversion of Git.  If we can change the distro's idea of what constitutes a\nrelease of Git that is on a single maintenance track from the current\n\"1.7.7.3 and newer, but not anything that does not begin with 1.7.7.\"  to\n\"1.7.9 and newer, but not anything that does not begin with 1.7.\", that\nwould be a major win, I would imagine.\n\nAnd dropping the maintenance tracks for older major releases may be a good\nfirst step in that right direction.\n\nWith that in mind, the real answer to the original question in this thread\nmay be \"the oldest supported version is the current one. stay at the\nlatest major release, in other words, do not even ask that question\".\n\nThoughts?\n"},{"id":"184748","messageId":"20120215053607.GC29902@sigill.intra.peff.net","threadId":"29523","inReplyTo":"7vwr7upj9m.fsf@alter.siamese.dyndns.org","subject":"Re: how to determine oldest supported version of git","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-15T05:36:07Z","receivedAt":"2012-02-15T05:36:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 10, 2012 at 11:42:45AM -0800, Junio C Hamano wrote:\n\n> Also our strict no regression policy means that it is not like an\n> option --foo in one version of Git changes its meaning from X to Y\n> across version boundaries, and even if on rare occasions we need to\n> introduce incompatibilities to improve the system, we give enough\n> advance warning and execute careful migration plans to ensure that\n> third-parties can keep up, and the \"fix at the oldest branch and merge\n> upwards\" policy means fixes to important bugs will be in all the\n> maintenance tracks, including the 'master' version.\n\nJust because we have a no-regression policy does not mean that we always\nsucceed. Bugs happen in new features. Hopefully the bugs only exist\nfor users of the new features, but occasionally they creep into\neverybody's workflow.\n\nIf you are running v1.7.8.1 now, even if v1.7.9 is out, it is less risky\nto move to v1.7.8.2 than to move to v1.7.9. Even though the risk of\nmoving to v1.7.9 is small, which I think is what you are arguing, it is\nstill greater than moving to a branch on which a release engineer (read:\nyou) has cherry-picked only ultra-safe bugfixes.\n\nI think you are perhaps arguing that we are so safe that the difference\nin risk is negligible. I do think we do better than many other projects,\nbut as a data storage project, I think it's nice to have a very\nconservative branch (OTOH, data-loss bugs have historically been\nextremely rare for git).\n\n> So in practical terms, once 1.7.9 is out, there is *no* practical reason\n> for anybody to use 1.7.8.x or anything older.\n\nWouldn't that also mean that v1.7.8.x has no reason to exist in the\nfirst place? That is, if it is truly safe to move to v1.7.9, then why\ndid we bother making maintenance releases in the first place? Why not\njust release the tip of master more frequently?\n\nI think the answer is that v1.7.9 is _not_ as safe. But v1.7.9.4\nprobably _is_. That is, v1.7.9 will introduce new features, and\nhopefully bugs will be shaken out while topics cook in master and next.\nBut once v1.7.9 is released, we get a much wider audience, and we will\nprobably find a few new bugs and some accidental regressions. Those will\nslowly get fixed and we will get new minor v1.7.9.x releases, until at\nsome point the v1.7.9.x series gets just as solid as the v1.7.8.x series\nwas.\n\nIOW, if you are on v1.7.8.2 and a we have a new bugfix, whether you want\na v1.7.8.3 or whether you jump to v1.7.9 should depend on where the\nv1.7.9 series is in terms of maturity.\n\nWhich implies to me that in an ideal world, there would be maint\nreleases for the current series (i.e., v1.7.9.x now) and the previous\none (v1.7.8.x now). Somewhere around v1.7.9.3 (or after 3 months, or\nwhatever), stop bothering with v1.7.8.x releases.\n\nOf course that takes time and effort (from you, mostly). If we dropped\nmaint releases entirely, then nobody would have to bother with the\nrelease engineering task of deciding which topics were safe, and which\nwere not.\n\n> If we only released the feature releases without _any_ maintenance\n> releases, distros no longer have an excuse to stick to older maintenance\n> tracks (\"For the upcoming Zesty Zebra LTS, Git will stay at 1.7.7.x and\n> never updated to any newer major version.\")\n\nI suspect that distros would not simply keep updating. Conservative\ndistros like Debian and RedHat (and probably Ubuntu LTSs, though I have\nno experience with that) have policies in place about what can and\nshould go into updates. And they will end up doing the release\nengineering themselves, staying on v1.7.7 + a bunch of cherry-picked\npatches.\n\nIn some ways, that's a good thing; they can deal with the release\nmanagement work. OTOH, it's duplicated effort, and done by people who\nare not as intimately familiar with git. A distro can probably pick up\nyour v1.7.8.x for an interim stable release without having to look\nthrough all of the patches themselves.\n\nOf course, the distros end up doing some of that release management\nthemselves, anyway. The git project's idea of \"old\" is 6-12 months, and\ndistros with long-term releases operate on much larger scales. So long\nafter we are tired of v1.7.8.x, they will probably still be\ncherry-picking patches onto it. So maybe it is not worth caring about\ndistro's release management, as we are only helping them for a few\nmonths, anyway.\n\n-Peff\n"},{"id":"184749","messageId":"7vaa4k38nj.fsf@alter.siamese.dyndns.org","threadId":"29523","inReplyTo":"20120215053607.GC29902@sigill.intra.peff.net","subject":"Re: how to determine oldest supported version of git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-02-15T06:36:32Z","receivedAt":"2012-02-15T06:36:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> If you are running v1.7.8.1 now, even if v1.7.9 is out, it is less risky\n> to move to v1.7.8.2 than to move to v1.7.9.\n\nThat has been the illusion I have been feeding the users.  Unfortunately,\nof all people even you started to believe it, because I have been doing\nsuch a good job in giving the illusion, not necessarily in actually\nkeeping the promise.\n\nBut think again, with the intimate knowledge of how these bugfix topics\nare merged down to older maintenance tracks.\n\nTypically, a new patch that looks reasonable lives in 'pu' only for a day\nor two, cook in 'next' for a couple of days to a few weeks, merged to\n'master' and then after several days to a week or two, further merged down\nto 'maint' and older maintenance tracks.\n\nI typically run 'next' and I presume so do many other Git people, so this\nprocedure has proven to be a reasonably robust way to ensure that by the\ntime the change hits 'master', it has been used in a context that is\nreasonably close to the surrounding code (by this word, I do not mean\n\"textually surrounding\" code here; what I mean are the things like the\ninternal state of the process prepared by existing code before it calls\nthe updated code, and the way the existing code uses data returned by the\nnew code) in its final destination that is 'master' for at least a week,\npreferrably longer. That gives us a stable 'master'.\n\nBut nobody in the development community rebuilds 'maint' every time it is\nupdated and runs the result as his or her primary production version. Even\nI do not do that (remember, I run 'next'). I only build and run full test\nsuite. Older maintenance tracks are worse. I do not think anybody runs\nthem before they are tagged and released.\n\nAnd because 'maint' is deliberately kept behind to exclude all the new\nfeatures, and occasional code restructuring associated with some of the\nnew features only happens in 'master' but never merged down to 'maint',\nthe surrounding code between 'master' and 'maint' can become vastly\ndifferent, making the risk of potential breakage coming from impedance\nmismatch higher. I would be very surprised if moving from 1.7.8.3 to\n1.7.8.4 were less risky than moving from 1.7.8.3 to 1.7.9.1.  You simply\ndo not really know what you are getting if you moved from 1.7.6.1 (which\nhas fixes proven in early 'master' of post 1.7.6 cycle, that was similar\nto 1.7.6) to 1.7.6.6 (which merges down fixes that were primarily tested\nonly in the context of post 1.7.8 cycle), so such a move is even riskier,\nsimply the base code has diverged too much.\n\n> moving to v1.7.9 is small, which I think is what you are arguing, it is\n> still greater than moving to a branch on which a release engineer (read:\n> you) has cherry-picked only ultra-safe bugfixes.\n\nThe key thing to realize is that they are ultra-safe in the context it has\nbeen cooking in.\n\n> I think you are perhaps arguing that we are so safe that the difference\n> in risk is negligible.\n\nQuite the contrary, I am saying that older and untested down-merges are\nmuch riskier, and the difference in risk should not be ignored.\n\n> Which implies to me that in an ideal world, there would be maint\n> releases for the current series (i.e., v1.7.9.x now) and the previous\n> one (v1.7.8.x now). Somewhere around v1.7.9.3 (or after 3 months, or\n> whatever), stop bothering with v1.7.8.x releases.\n\nActually what I was thinking was to restructure the release schedule\nslightly so that\n\n * We do not merge to 'master' anything but bugfix patches to regressions\n   introduced by 1.7.10 or to new features introduced by 1.7.10, for two\n   weeks after it ships;\n\n * During that time, if an urgent fix is needed, 'maint' is directly\n   patched to produce 1.7.9.X, and it is merged upward to 'next';\n\n * After finishing applying the early fixes to 1.7.10 to 'master', we tag\n   the tip of 'master' as 1.7.10.1 and fork 'maint' from there;\n\n * At that point, old 'maint' and 1.7.9.X track cease to receive updates,\n   as there is no point maintaining them. It only encourages distros to\n   stay behind, adding unnecesary maintenance burden to us.\n\n> In some ways, that's a good thing; they can deal with the release\n> management work. OTOH, it's duplicated effort, and done by people who\n> are not as intimately familiar with git.\n\nYes, that's the crucial observation to make.  Cherry-picking or down\nmerging fixes tested in a new context to older codebase that is not\nactively used by the person who is cherry-picking does not produce a\nstable end product. It only produces stale end product.  It makes it\nslightly scarier to imagine that the cherry-pick is done by people who\nmay not be as familiar with the codebase as us, but on the other hand,\nthey might be using that old codebase for their day-to-day work, and may\nhave better luck hitting issues that did not manifest themselves in the\ncontext of 'master' and 'next.\n"},{"id":"184753","messageId":"20120215091526.GA22683@sigill.intra.peff.net","threadId":"29523","inReplyTo":"7vaa4k38nj.fsf@alter.siamese.dyndns.org","subject":"Re: how to determine oldest supported version of git","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-02-15T09:15:26Z","receivedAt":"2012-02-15T09:15:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 14, 2012 at 10:36:32PM -0800, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > If you are running v1.7.8.1 now, even if v1.7.9 is out, it is less risky\n> > to move to v1.7.8.2 than to move to v1.7.9.\n> [...]\n> But nobody in the development community rebuilds 'maint' every time it is\n> updated and runs the result as his or her primary production version. Even\n> I do not do that (remember, I run 'next'). I only build and run full test\n> suite. Older maintenance tracks are worse. I do not think anybody runs\n> them before they are tagged and released.\n\nThat's a good point. Maint releases are not well tested before release.\nHowever, I think there are two things that help balance that:\n\n  1. The commits that go onto them are \"obviously\" correct. I put\n     obviously in quotes, because of course we can make a mistake. But\n     just looking at the commits that end up in a typical maint release,\n     they're usually quite conservative.\n\n     So in deciding between v1.7.8.4 or v1.7.9, it is a question of\n     whether you are more likely to be screwed by a conservative commit\n     that has gotten less testing, or by one of the host of\n     non-conservative commits that have gotten more testing.\n\n     I don't think we have numbers on the historical balance (and going\n     forward, it would really depend on qualitative factors like \"how\n     conservative\" anyway).\n\n  2. The commits on maint are often tested in isolation. That is, they\n     are not generally cherry-picks, but were rather branched and\n     developed from a maint-worthy version, and then forward ported into\n     master (where forward porting for us is basically merging plus\n     adding any required tweaks). So in an ideal world, the developer\n     considers the fix looking at the maint code, and then the risky\n     forward-porting happens in master (where we have time to cook and\n     squash bugs).\n\n     On the other hand, just because the developer comes up with the fix\n     based on an old version doesn't mean that they don't make a\n     mistake. And with nobody running it, those mistakes may slip\n     through. Also, we do sometimes base bugfixes on the source of a\n     bug, which is ancient, and then merge up not only to master but\n     also to maint.  The right fix at the source of the bug may be\n     different than what is needed at maint, which is different than\n     what is needed at master.\n\nHmm. I really wish we had some numbers, because it's very unclear to me\nwhich factor dominates. My gut says that the maint releases are still\nsafer, even with the problems you listed. I recall multiple bugs in\nfeature releases that caused quick bugfix releases. I don't recall\noffhand having to quickly issue a fix for a maintenance release.\n\n> > Which implies to me that in an ideal world, there would be maint\n> > releases for the current series (i.e., v1.7.9.x now) and the previous\n> > one (v1.7.8.x now). Somewhere around v1.7.9.3 (or after 3 months, or\n> > whatever), stop bothering with v1.7.8.x releases.\n> \n> Actually what I was thinking was to restructure the release schedule\n> slightly so that\n> \n>  * We do not merge to 'master' anything but bugfix patches to regressions\n>    introduced by 1.7.10 or to new features introduced by 1.7.10, for two\n>    weeks after it ships;\n> \n>  * During that time, if an urgent fix is needed, 'maint' is directly\n>    patched to produce 1.7.9.X, and it is merged upward to 'next';\n> \n>  * After finishing applying the early fixes to 1.7.10 to 'master', we tag\n>    the tip of 'master' as 1.7.10.1 and fork 'maint' from there;\n> \n>  * At that point, old 'maint' and 1.7.9.X track cease to receive updates,\n>    as there is no point maintaining them. It only encourages distros to\n>    stay behind, adding unnecesary maintenance burden to us.\n\nI think that is not so far from what I proposed (except that my \"3\nmonths or whatever\" is your \"2 weeks and one version\").\n\n> Yes, that's the crucial observation to make.  Cherry-picking or down\n> merging fixes tested in a new context to older codebase that is not\n> actively used by the person who is cherry-picking does not produce a\n> stable end product. It only produces stale end product.  It makes it\n> slightly scarier to imagine that the cherry-pick is done by people who\n> may not be as familiar with the codebase as us, but on the other hand,\n> they might be using that old codebase for their day-to-day work, and may\n> have better luck hitting issues that did not manifest themselves in the\n> context of 'master' and 'next.\n\nGood point. I thought of them as less-qualified, but in many ways they\nare more so.\n\nHmph. You've certainly given me something to think about. I joined this\nthread thinking you were a little bit crazy, but now I think you are\nstarting to convince me. :)\n\n-Peff\n"},{"id":"184777","messageId":"20120215183454.GA23016@burratino","threadId":"29523","inReplyTo":"7vaa4k38nj.fsf@alter.siamese.dyndns.org","subject":"Re: how to determine oldest supported version of git","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-02-15T18:34:54Z","receivedAt":"2012-02-15T18:34:54Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> But think again, with the intimate knowledge of how these bugfix topics\n> are merged down to older maintenance tracks.\n[...]\n> But nobody in the development community rebuilds 'maint' every time it is\n> updated and runs the result as his or her primary production version. Even\n> I do not do that (remember, I run 'next'). I only build and run full test\n> suite. Older maintenance tracks are worse. I do not think anybody runs\n> them before they are tagged and released.\n\nI can offer one data point.  In the context of Debian sid, Gerrit and\nI do test each version in daily work before uploading it.  I generally\nbuild from and test whatever track is going to be used for the next\nupload (usually plus a few extra features I am interested in for\nprivate use) a little while before the release, to be prepared.\nAnders sometimes uploads to the Ubuntu PPA which brings more testers.\nAfter the upload, users running \"sid\" test for about a week before\neven more users running \"testing\" get to take a look at it and test\nfor the sake of later users who will run \"stable\".\n\nSo little bugs get discovered, with time to fix them.\n\nEven with this, the extra time to migrate from 1.7.6 to 1.7.7, for\nexample, was very helpful in the context of Debian sid.  Like it or\nnot, new features *do* come with minor regressions, and it helps the\nsanity of a package maintainer to not have to suffer people who did\nnot request a bleeding-edge release complaining about regressions\nuntil there has been time to fix them.\n\nOf course, this has nothing to do with Debian stable, which is an\northogonal story.  I'll discuss that below.\n\n[...]\n>  * At that point, old 'maint' and 1.7.9.X track cease to receive updates,\n>    as there is no point maintaining them. It only encourages distros to\n>    stay behind, adding unnecesary maintenance burden to us.\n\nIf you are thinking of distros like Debian stable, then that is just\nwishful thinking.  Dropping support for old releases does not have any\neffect except to cause patches to be missed there.  (See iceweasel and\nchromium-browser for examples where using the version in Debian stable\nis something I would usually not recommend.)\n\nThis may seem weird, but keep in mind that people like you and me are\nnot the target audience for the git package in Debian stable.  We use\ngit heavily.  If I am on a machine running stable or RHEL, I will\nbuild a private copy of git in $HOME or ask the sysadmin to install a\nmore recent git as the first thing I do.\n\nThe reason that packages go into Debian stable and then just _don't\nchange_ is that the target users are not using those packages heavily.\nIf a new feature (e.g., \"signatures from tags get incorporated into\nthe merge commit from pulling them\") causes a regression (e.g., \"the\nscript I used to run every week that pulls my favorite software\npackage and builds it just stopped working\"), then these people get\nzero benefit, for a sizable cost.\n\nThough that's a digression.  The relevant detail to mention here is\nthat there is real demand on downstreams to continue to maintain\npackages without adding new features.  They will help to maintain\nold releases if you want.  If we want to influence that maintainance,\nfor example to ensure security bugs are fixed correctly and in the\nsame way everywhere, a good way is to keep a maintenance branch.\n\nHoping that clarifies a little.\nJonathan\n"},{"id":"184779","messageId":"20120215184408.GA23119@burratino","threadId":"29523","inReplyTo":"20120215183454.GA23016@burratino","subject":"Re: how to determine oldest supported version of git","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-02-15T18:44:08Z","receivedAt":"2012-02-15T18:44:08Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jonathan Nieder wrote:\n\n> Even with this, the extra time to migrate from 1.7.6 to 1.7.7, for\n> example, was very helpful in the context of Debian sid.\n\nWhoops, off by one error.  The extra time to move from 1.7.4 to 1.7.5\nand 1.7.5 to 1.7.6 was helpful.  1.7.7 was actually pretty painless,\nso sid moved to it right away. ;-)\n"}]}