Short-term plans for the post 2.9 cycle

Short-term plans for the post 2.9 cycle

[Junio C Hamano]

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.

Re: Short-term plans for the post 2.9 cycle

[Stefan Beller]

On Sun, Jun 19, 2016 at 3:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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.
>

Thanks for such an overview!

Re: Short-term plans for the post 2.9 cycle

[Junio C Hamano]

On Mon, Jun 20, 2016 at 9:46 AM, Stefan Beller <sbeller@google.com> wrote:
> On Sun, Jun 19, 2016 at 3:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> 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.
>>
>
> Thanks for such an overview!

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).

Re: Short-term plans for the post 2.9 cycle

[Jeff King]

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

> 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'.

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

Re: Short-term plans for the post 2.9 cycle

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> ...  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.

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.

Re: Short-term plans for the post 2.9 cycle

[Jeff King]

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

> Jeff King <peff@peff.net> writes:
> 
> > ...  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.
> 
> 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.

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

-Peff