Jeff King <peff@xxxxxxxx> writes: > If you are running v1.7.8.1 now, even if v1.7.9 is out, it is less risky > to move to v1.7.8.2 than to move to v1.7.9. That has been the illusion I have been feeding the users. Unfortunately, of all people even you started to believe it, because I have been doing such a good job in giving the illusion, not necessarily in actually keeping the promise. But think again, with the intimate knowledge of how these bugfix topics are merged down to older maintenance tracks. Typically, a new patch that looks reasonable lives in 'pu' only for a day or two, cook in 'next' for a couple of days to a few weeks, merged to 'master' and then after several days to a week or two, further merged down to 'maint' and older maintenance tracks. I typically run 'next' and I presume so do many other Git people, so this procedure has proven to be a reasonably robust way to ensure that by the time the change hits 'master', it has been used in a context that is reasonably close to the surrounding code (by this word, I do not mean "textually surrounding" code here; what I mean are the things like the internal state of the process prepared by existing code before it calls the updated code, and the way the existing code uses data returned by the new code) in its final destination that is 'master' for at least a week, preferrably longer. That gives us a stable 'master'. But nobody in the development community rebuilds 'maint' every time it is updated and runs the result as his or her primary production version. Even I do not do that (remember, I run 'next'). I only build and run full test suite. Older maintenance tracks are worse. I do not think anybody runs them before they are tagged and released. And because 'maint' is deliberately kept behind to exclude all the new features, and occasional code restructuring associated with some of the new features only happens in 'master' but never merged down to 'maint', the surrounding code between 'master' and 'maint' can become vastly different, making the risk of potential breakage coming from impedance mismatch higher. I would be very surprised if moving from 1.7.8.3 to 1.7.8.4 were less risky than moving from 1.7.8.3 to 1.7.9.1. You simply do not really know what you are getting if you moved from 1.7.6.1 (which has fixes proven in early 'master' of post 1.7.6 cycle, that was similar to 1.7.6) to 1.7.6.6 (which merges down fixes that were primarily tested only in the context of post 1.7.8 cycle), so such a move is even riskier, simply the base code has diverged too much. > moving to v1.7.9 is small, which I think is what you are arguing, it is > still greater than moving to a branch on which a release engineer (read: > you) has cherry-picked only ultra-safe bugfixes. The key thing to realize is that they are ultra-safe in the context it has been cooking in. > I think you are perhaps arguing that we are so safe that the difference > in risk is negligible. Quite the contrary, I am saying that older and untested down-merges are much riskier, and the difference in risk should not be ignored. > Which implies to me that in an ideal world, there would be maint > releases for the current series (i.e., v1.7.9.x now) and the previous > one (v1.7.8.x now). Somewhere around v1.7.9.3 (or after 3 months, or > whatever), stop bothering with v1.7.8.x releases. Actually what I was thinking was to restructure the release schedule slightly so that * We do not merge to 'master' anything but bugfix patches to regressions introduced by 1.7.10 or to new features introduced by 1.7.10, for two weeks after it ships; * During that time, if an urgent fix is needed, 'maint' is directly patched to produce 1.7.9.X, and it is merged upward to 'next'; * After finishing applying the early fixes to 1.7.10 to 'master', we tag the tip of 'master' as 1.7.10.1 and fork 'maint' from there; * At that point, old 'maint' and 1.7.9.X track cease to receive updates, as there is no point maintaining them. It only encourages distros to stay behind, adding unnecesary maintenance burden to us. > In some ways, that's a good thing; they can deal with the release > management work. OTOH, it's duplicated effort, and done by people who > are not as intimately familiar with git. Yes, that's the crucial observation to make. Cherry-picking or down merging fixes tested in a new context to older codebase that is not actively used by the person who is cherry-picking does not produce a stable end product. It only produces stale end product. It makes it slightly scarier to imagine that the cherry-pick is done by people who may not be as familiar with the codebase as us, but on the other hand, they might be using that old codebase for their day-to-day work, and may have better luck hitting issues that did not manifest themselves in the context of 'master' and 'next. -- 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