{"thread":{"id":"42664","subject":"Short-term plans for the post 2.9 cycle","startedAt":"2016-06-19T22:52:44Z","lastAt":"2016-06-24T17:22:11Z","messageCount":6,"participants":["Junio C Hamano","Stefan Beller","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"289646","messageId":"xmqqh9covlkb.fsf@gitster.mtv.corp.google.com","threadId":"42664","inReplyTo":null,"subject":"Short-term plans for the post 2.9 cycle","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-19T22:52:04Z","receivedAt":"2016-06-19T22:52:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the list of topics that are in the \"private edition\" I use\nfor every day work, grouped by where they sit in the the near-term\nplan of merging them up to 'next' and then to 'master'.\n\nThese will be merged to 'master' soonish.\n\n ew/fast-import-unpack-limit\n ah/no-verify-signature-with-pull-rebase\n ew/daemon-socket-keepalive\n sb/submodule-misc-cleanups\n sb/submodule-recommend-shallowness\n et/pretty-format-c-auto\n jg/dash-is-last-branch-in-worktree-add\n aq/upload-pack-use-parse-options\n jc/clear-pathspec\n wd/userdiff-css\n jk/rev-list-count-with-bitmap\n rs/xdiff-hunk-with-func-line\n\nThese will be in 'next' immediately after the above gets merged to\n'master'.\n\n cc/apply-introduce-state\n\nThese have been in 'next', but will be kicked back to give them\nchance to clean up when 'next' is rewound.\n\n mh/split-under-lock\n mh/ref-iterators\n jc/attr\n sb/pathspec-label\n\nThese are expected to be merged to 'next' in the first batch after\n'next' gets rewound.\n\n pc/occurred\n tr/doc-tt\n ap/git-svn-propset-doc\n jk/fetch-prune-doc\n dn/gpg-doc\n pb/strbuf-read-file-doc\n lf/receive-pack-auto-gc-to-client\n mg/cherry-pick-multi-on-unborn\n sg/reflog-past-root\n vs/prompt-avoid-unset-variable\n rj/compat-regex-size-max-fix\n jk/avoid-unbounded-alloca\n et/add-chmod-x\n jc/deref-tag\n nb/gnome-keyring-build\n lv/status-say-working-tree-not-directory\n tb/complete-status\n em/newer-freebsd-shells-are-fine-with-returns\n\nThese are the second batch for 'next'.\n\n km/fetch-do-not-free-remote-name\n jk/parseopt-string-list\n jk/string-list-static-init\n lf/sideband-returns-void\n jk/bisect-show-tree\n jk/add-i-diff-compact-heuristics\n jk/big-and-future-archive-tar\n jk/send-pack-stdio\n lf/recv-sideband-cleanup\n pb/commit-editmsg-path\n nd/test-lib-httpd-show-error-log-in-verbose\n ep/http-curl-trace\n\nThese are the third batch.\n\n mh/connect\n ew/mboxrd-format-am\n jk/repack-keep-unreachable\n jk/gpg-interface-cleanup\n sb/submodule-clone-retry\n mg/signature-doc\n\nThese are the fourth.\n\n nd/worktree-cleanup-post-head-protection\n jk/upload-pack-hook\n nd/graph-width-padded\n nd/shallow-deepen\n sb/submodule-default-paths\n nd/worktree-lock\n\nThese are the remainder.\n\n jc/blame-reverse\n jc/send-email-skip-backup\n va/i18n-even-more\n dt/index-helper\n dk/blame-move-no-reason-for-1-line-context\n sb/clone-shallow-passthru\n\nSome of them that are regression fixes may need to jump the queue\nand land on 'master' earlier than others.\n"},{"id":"289681","messageId":"CAGZ79kaHRz2GZN4FmQBA1wz4FhBWDwVifWX_bN09TAHAxF-wQA@mail.gmail.com","threadId":"42664","inReplyTo":"xmqqh9covlkb.fsf@gitster.mtv.corp.google.com","subject":"Re: Short-term plans for the post 2.9 cycle","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-06-20T16:46:02Z","receivedAt":"2016-06-20T16:47:24Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Sun, Jun 19, 2016 at 3:52 PM, Junio C Hamano wrote:\n> Here are the list of topics that are in the \"private edition\" I use\n> for every day work, grouped by where they sit in the the near-term\n> plan of merging them up to 'next' and then to 'master'.\n>\n> These will be merged to 'master' soonish.\n>\n\nThanks for such an overview!\n"},{"id":"289683","messageId":"CAPc5daXg+RFYwp9g6NLvH5bCei2kjWy70Gm3vGnZVCTxqGLFRw@mail.gmail.com","threadId":"42664","inReplyTo":"CAGZ79kaHRz2GZN4FmQBA1wz4FhBWDwVifWX_bN09TAHAxF-wQA@mail.gmail.com","subject":"Re: Short-term plans for the post 2.9 cycle","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-20T17:05:47Z","receivedAt":"2016-06-20T17:06:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Mon, Jun 20, 2016 at 9:46 AM, Stefan Beller wrote:\n> On Sun, Jun 19, 2016 at 3:52 PM, Junio C Hamano wrote:\n>> Here are the list of topics that are in the \"private edition\" I use\n>> for every day work, grouped by where they sit in the the near-term\n>> plan of merging them up to 'next' and then to 'master'.\n>>\n>> These will be merged to 'master' soonish.\n>>\n>\n> Thanks for such an overview!\n\nFYI, this can be obtained by running \"git log --oneline --first-parent\nmaster..pu\".\nThe point where \"Merge ... into jch\" ends is what I usually use myself\n(IOW, I do\nattempt to build and test 'pu', but I do not run it regularly).\n"},{"id":"290025","messageId":"20160624154800.GB2448@sigill.intra.peff.net","threadId":"42664","inReplyTo":"xmqqh9covlkb.fsf@gitster.mtv.corp.google.com","subject":"Re: Short-term plans for the post 2.9 cycle","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-06-24T15:48:01Z","receivedAt":"2016-06-24T15:48:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jun 19, 2016 at 03:52:04PM -0700, Junio C Hamano wrote:\n\n> Here are the list of topics that are in the \"private edition\" I use\n> for every day work, grouped by where they sit in the the near-term\n> plan of merging them up to 'next' and then to 'master'.\n\nBy the way, I wondered if you had thoughts on the number of the upcoming\nversion. We are looking at v2.10 in the current scheme. It was at the\nv1.9/v1.10 boundary that we jumped to v2.0 last time.\n\nCertainly it is nice to avoid bumping into double digits (if only to\nprevent bugs created by lexical sorting). But it feels rather quick to\nbe jumping to v3.0. And indeed it is much quicker, as the v1.x series\nhad an extra level of versioning which meant that the second-biggest\nnumber advanced ten times more slowly.\n\nI know some people's opinion is that versions do not matter, are just\nnumbers, etc, but I am not sure I agree. If you have dots in your\nversion number, then bumping the one before the first dot seems like a\nbigger change than usual, and I think we should reserve it for a moment\nwhere we have bigger changes in the code.\n\nAnd I am not at all sure that we have given much thought to what such\nchanges would be, or that such things would be ready in this cycle. Off\nthe top of my head, the repository-format bump for pluggable ref\nbackends, and protocol v2 support seem like possible candidates. It's\nnot a flag day for either, of course; we'll build in all of the usual\nbackwards-compatibility flags. But it's convenient for users to remember\nthat \"3.0\" is the minimum to support a new slate of\nbackwards-incompatible features.\n\nSo my inclination is that the next version is simply v2.10. And maybe\nyou thought of all of this already, and that's why you didn't even\nbother mentioning it. :) I'm just curious to hear any thoughts on the\nmatter.\n\n-Peff\n"},{"id":"290030","messageId":"xmqqd1n6h6iq.fsf@gitster.mtv.corp.google.com","threadId":"42664","inReplyTo":"20160624154800.GB2448@sigill.intra.peff.net","subject":"Re: Short-term plans for the post 2.9 cycle","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-06-24T16:54:21Z","receivedAt":"2016-06-24T16:54:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> ... It's\n> not a flag day for either, of course; we'll build in all of the usual\n> backwards-compatibility flags. But it's convenient for users to remember\n> that \"3.0\" is the minimum to support a new slate of\n> backwards-incompatible features.\n>\n> So my inclination is that the next version is simply v2.10. And maybe\n> you thought of all of this already, and that's why you didn't even\n> bother mentioning it. :) I'm just curious to hear any thoughts on the\n> matter.\n\nYou traced my thought very precisely. If you take the \"It is for\ncompatibility breaking release\" and \"We plan such a release well in\nadvance with transition period\" together, a natural consequence is\nthat by the time we tag one release (e.g. v2.9), it is expected that\nthe release notes for it and a few previous releases would all have\nsaid \"in v3.0, this and that things need to be adjusted, but the\npast few releases should have prepared all of you for that change\".\n\nSo, no. I do not think the next one can sensibly be v3.0.\n\nDuring this cycle what can happen at most is that harbingers of\ncompatibility breakers conceived, transition plans for them laid\nout, and the first step for these compatibility breakers included.\nThat will still not qualify for a version bump. The follow-up steps\nfor these compatibility breakers may start cooking in 'next', and\nduring the next cycle the list may agree they are ready for the\nupcoming release. At that point, before tagging the last release in\nv2.x series, we already know that the cycle after that will be v3.0\nto include these compatibility breakers.\n\n\n"},{"id":"290033","messageId":"20160624172157.GB3273@sigill.intra.peff.net","threadId":"42664","inReplyTo":"xmqqd1n6h6iq.fsf@gitster.mtv.corp.google.com","subject":"Re: Short-term plans for the post 2.9 cycle","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-06-24T17:21:58Z","receivedAt":"2016-06-24T17:22:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 24, 2016 at 09:54:21AM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > ... It's\n> > not a flag day for either, of course; we'll build in all of the usual\n> > backwards-compatibility flags. But it's convenient for users to remember\n> > that \"3.0\" is the minimum to support a new slate of\n> > backwards-incompatible features.\n> >\n> > So my inclination is that the next version is simply v2.10. And maybe\n> > you thought of all of this already, and that's why you didn't even\n> > bother mentioning it. :) I'm just curious to hear any thoughts on the\n> > matter.\n> \n> You traced my thought very precisely. If you take the \"It is for\n> compatibility breaking release\" and \"We plan such a release well in\n> advance with transition period\" together, a natural consequence is\n> that by the time we tag one release (e.g. v2.9), it is expected that\n> the release notes for it and a few previous releases would all have\n> said \"in v3.0, this and that things need to be adjusted, but the\n> past few releases should have prepared all of you for that change\".\n> \n> So, no. I do not think the next one can sensibly be v3.0.\n> \n> During this cycle what can happen at most is that harbingers of\n> compatibility breakers conceived, transition plans for them laid\n> out, and the first step for these compatibility breakers included.\n> That will still not qualify for a version bump. The follow-up steps\n> for these compatibility breakers may start cooking in 'next', and\n> during the next cycle the list may agree they are ready for the\n> upcoming release. At that point, before tagging the last release in\n> v2.x series, we already know that the cycle after that will be v3.0\n> to include these compatibility breakers.\n\nThanks, that spells out much better my \"we are not ready\" thoughts, and\nI am in complete agreement.\n\n-Peff\n"}]}