threads / discuss / 35485

Next cycle may be for 1.9 ...

Subject: Next cycle may be for 1.9 ...

## tl;dr

One message between Dec 6, 2013 and Dec 6, 2013.

replies: 0people: 1as markdown or json

Junio C Hamano· Dec 6, 2013, 00:06 UTC · lore

... instead of 1.8.6 (which would have been the name if we were on auto-pilot), so that the version that comes after it will logically be 2.0. Distro people may want to make sure that they are not hardcoding "three-dewey-decimal are feature releases, four-dewey-decimal are maintenance releases" heuristics in their build system.

I haven't rewound 'next', but plan to drop three topics when I do so:

 * aa/transport-non-positive-depth-only
  + transport: catch non positive --depth option value
 My understanding is that Duy sent out a replacement ($gmane/238841)
 for this one.
* cc/remote-remove-redundant-postfixcmp
 + Rename suffixcmp() to has_suffix() and invert its result
 + builtin/remote: remove postfixcmp() and use suffixcmp() instead
 This is superseded by cc/starts-n-ends-with topic.
* th/reflog-annotated-tag (2013-10-28)
 + reflog: handle lightweight and annotated tags equally
 This needs to be reworked, as it is incomplete and merely sweeping
 the real problem (i.e. there is no code to handle the case) under
 the rug.

Also, contrary to what I said earlier, I am tempted to include the removal of the ancient deprecated commands in the next release.

* jk/remove-deprecated
 + stop installing git-tar-tree link
 + peek-remote: remove deprecated alias of ls-remote
 + lost-found: remove deprecated command
 + tar-tree: remove deprecated command
 + repo-config: remove deprecated alias for "git config"
Thanks.

← back to recent threads