Junio C Hamano <gitster@xxxxxxxxx> writes: > But "in retrospect we should have called it 2.0" is patently false; > switching from 3-tuple version numbers to 2-tuple version numbers > has nothing to do with introducing breaking changes. I tried to make it concise, and came up with the following on top of tweaked [v6 1/4] on 'seen'. Documentation/BreakingChanges.txt | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git c/Documentation/BreakingChanges.txt w/Documentation/BreakingChanges.txt index d977915e52..9c2c5f2328 100644 --- c/Documentation/BreakingChanges.txt +++ w/Documentation/BreakingChanges.txt @@ -21,12 +21,19 @@ change in user-visible behavior. The Git project irregularly releases breaking versions that deliberately break backwards compatibility with older versions. This is done to ensure that Git remains relevant, safe and maintainable going forward. The release cadence of -breaking versions is typically measured in multiple years. The last breaking -releases were: +breaking versions is typically measured in multiple years. We had major +breaking releases like these in the past: -* Git 1.6, released in August 2008. +* Git 1.6.0, released in August 2008. * Git 2.0, released in May 2014. +We use <major>.<minor> release numbers these days, starting from Git +2.0, for feature releases, our plan is to increment <major> in the +release number when we make the next breaking release (before Git 2.0, +the release numbers were 1.<major>.<minor> with the intention to increment +<major> for "usual" breaking releases, reserving the jump to Git 2.0 for +really large backward-compatibility breaking changes). + The intent of this document is to track upcoming deprecations for future breaking releases. Furthermore, this document also tracks what will _not_ be deprecated. This is done such that the outcome of discussions document both
