Re: [PATCH v6 1/4] docs: introduce document to announce breaking changes

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 5, 2024, 16:03 UTC
Message-ID: <xmqqjzj3wf4m.fsf@gitster.g>
In-Reply-To: <Zl_4IIqFmoPhx1Gc@tanuki>

Patrick Steinhardt <ps@pks.im> writes:

Show 19 quoted lines

> On Tue, Jun 04, 2024 at 10:59:52AM -0700, Junio C Hamano wrote:
>> Patrick Steinhardt <ps@pks.im> writes:
>> 
>> > +* Git 1.6, released in August 2008. In retrospect, this release should likely
>> > +  have bumped the major version.
>> 
>> No need to reroll just for this alone, but back then, a non-zero
>> third component did not mean they are maintenance releases (e.g.,
>> v1.5.3.3 was the third maintenance update for the v1.5.3 series) and
>> v1.6.0 _was_ a departure, a breaking change from the v1.5.x series.
>> 
>> It is more recent tradition that we only use three numbers.  I'd
>> strike the whole "In retrospect" comment if I were writing this.
>
> The reason why I included it is that I didn't want to create the
> impression that breaking releases may also happen when bumping the
> second version component. It did happen with v1.6.0, but in the future I
> think we'd want to always bump the first component on such releases, do
> we?

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.

It needs to be rewritten in such a way that the readers would understand the following:

	Git 1.6.0, released in August 2008.

	These days, we use two-tuple numbers for feature releases
	(e.g. Git 2.45 and Git 2.45.0 with 0 as the third number are
	the same things) and maintenance releases have non-zero
	third number, so instead of going from Git 2.56 to Git 2.57,
	we would jump to Git 3.0 if we decide to make Git 2.56 the
	last feature release of the Git 2.0 series.

	With the versioning scheme used back then, going from Git
	1.5.6 to Git 1.5.7 would have been equivalent move to Git
	2.56 to Git 2.57, i.e. incremental and non-breaking feature
	release progression.  Deciding to go from Git 1.5.6 to Git
	1.6.0, instead of going to Git 1.5.7, was akin to moving to
	Git 3.0, signalling a breaking change, in today's versioning
	scheme.  We were reserving the increment to the first digit
	for even larger breaking changes until Git 2.0 happened.

Between Git 1.6.6 and Git 1.7.0, there were breaking changes. The same is true for the transtions between Git 1.7.12 and Git 1.8.0, between Git 1.4.4 and Git 1.5.0, and so on. They weren't as huge and controversial as the jump to Git 1.6.0, though.