Short-term plans for the post 2.9 cycle

Here are the list of topics that are in the "private edition" I use for every day work, grouped by where they sit in the the near-term plan of merging them up to 'next' and then to 'master'.

These will be merged to 'master' soonish.

 ew/fast-import-unpack-limit
 ah/no-verify-signature-with-pull-rebase
 ew/daemon-socket-keepalive
 sb/submodule-misc-cleanups
 sb/submodule-recommend-shallowness
 et/pretty-format-c-auto
 jg/dash-is-last-branch-in-worktree-add
 aq/upload-pack-use-parse-options
 jc/clear-pathspec
 wd/userdiff-css
 jk/rev-list-count-with-bitmap
 rs/xdiff-hunk-with-func-line

These will be in 'next' immediately after the above gets merged to 'master'.

 cc/apply-introduce-state

These have been in 'next', but will be kicked back to give them chance to clean up when 'next' is rewound.

 mh/split-under-lock
 mh/ref-iterators
 jc/attr
 sb/pathspec-label

These are expected to be merged to 'next' in the first batch after 'next' gets rewound.

 pc/occurred
 tr/doc-tt
 ap/git-svn-propset-doc
 jk/fetch-prune-doc
 dn/gpg-doc
 pb/strbuf-read-file-doc
 lf/receive-pack-auto-gc-to-client
 mg/cherry-pick-multi-on-unborn
 sg/reflog-past-root
 vs/prompt-avoid-unset-variable
 rj/compat-regex-size-max-fix
 jk/avoid-unbounded-alloca
 et/add-chmod-x
 jc/deref-tag
 nb/gnome-keyring-build
 lv/status-say-working-tree-not-directory
 tb/complete-status
 em/newer-freebsd-shells-are-fine-with-returns

These are the second batch for 'next'.

 km/fetch-do-not-free-remote-name
 jk/parseopt-string-list
 jk/string-list-static-init
 lf/sideband-returns-void
 jk/bisect-show-tree
 jk/add-i-diff-compact-heuristics
 jk/big-and-future-archive-tar
 jk/send-pack-stdio
 lf/recv-sideband-cleanup
 pb/commit-editmsg-path
 nd/test-lib-httpd-show-error-log-in-verbose
 ep/http-curl-trace

These are the third batch.

 mh/connect
 ew/mboxrd-format-am
 jk/repack-keep-unreachable
 jk/gpg-interface-cleanup
 sb/submodule-clone-retry
 mg/signature-doc

These are the fourth.

 nd/worktree-cleanup-post-head-protection
 jk/upload-pack-hook
 nd/graph-width-padded
 nd/shallow-deepen
 sb/submodule-default-paths
 nd/worktree-lock

These are the remainder.

 jc/blame-reverse
 jc/send-email-skip-backup
 va/i18n-even-more
 dt/index-helper
 dk/blame-move-no-reason-for-1-line-context
 sb/clone-shallow-passthru

Some of them that are regression fixes may need to jump the queue and land on 'master' earlier than others.

On Sun, Jun 19, 2016 at 3:52 PM, Junio C Hamano <gitster@pobox.com> wrote:

Thanks for such an overview!

On Mon, Jun 20, 2016 at 9:46 AM, Stefan Beller <sbeller@google.com> wrote:

FYI, this can be obtained by running "git log --oneline --first-parent master..pu". The point where "Merge ... into jch" ends is what I usually use myself (IOW, I do attempt to build and test 'pu', but I do not run it regularly).

On Sun, Jun 19, 2016 at 03:52:04PM -0700, Junio C Hamano wrote:

By the way, I wondered if you had thoughts on the number of the upcoming version. We are looking at v2.10 in the current scheme. It was at the v1.9/v1.10 boundary that we jumped to v2.0 last time.

Certainly it is nice to avoid bumping into double digits (if only to prevent bugs created by lexical sorting). But it feels rather quick to be jumping to v3.0. And indeed it is much quicker, as the v1.x series had an extra level of versioning which meant that the second-biggest number advanced ten times more slowly.

I know some people's opinion is that versions do not matter, are just numbers, etc, but I am not sure I agree. If you have dots in your version number, then bumping the one before the first dot seems like a bigger change than usual, and I think we should reserve it for a moment where we have bigger changes in the code.

And I am not at all sure that we have given much thought to what such changes would be, or that such things would be ready in this cycle. Off the top of my head, the repository-format bump for pluggable ref backends, and protocol v2 support seem like possible candidates. It's not a flag day for either, of course; we'll build in all of the usual backwards-compatibility flags. But it's convenient for users to remember that "3.0" is the minimum to support a new slate of backwards-incompatible features.

So my inclination is that the next version is simply v2.10. And maybe you thought of all of this already, and that's why you didn't even bother mentioning it. :) I'm just curious to hear any thoughts on the matter.

-Peff

Jeff King <peff@peff.net> writes:

You traced my thought very precisely. If you take the "It is for compatibility breaking release" and "We plan such a release well in advance with transition period" together, a natural consequence is that by the time we tag one release (e.g. v2.9), it is expected that the release notes for it and a few previous releases would all have said "in v3.0, this and that things need to be adjusted, but the past few releases should have prepared all of you for that change".

So, no. I do not think the next one can sensibly be v3.0.

During this cycle what can happen at most is that harbingers of compatibility breakers conceived, transition plans for them laid out, and the first step for these compatibility breakers included. That will still not qualify for a version bump. The follow-up steps for these compatibility breakers may start cooking in 'next', and during the next cycle the list may agree they are ready for the upcoming release. At that point, before tagging the last release in v2.x series, we already know that the cycle after that will be v3.0 to include these compatibility breakers.

On Fri, Jun 24, 2016 at 09:54:21AM -0700, Junio C Hamano wrote:

Thanks, that spells out much better my "we are not ready" thoughts, and I am in complete agreement.

-Peff