Junio C Hamano <gitster@xxxxxxxxx> writes:
> "Neal Kreitzinger" <neal@xxxxxxxx> writes:
>
>> What is the best way for me (a git user) to determine what is currently
>> the oldest supported version of git (the oldest version still getting
>> bugfixes)? IOW, when can I tell that my version of git is no longer
>> supported?
>
> "A note from the maintainer" only promises that the latest major release
> (as of this writing, 1.7.9) gets regular maintenance releases until the
> next major release happens.
>
> When queuing a fix to an old bug, however, I try to build a topic branch
> for that fix from as old an release as practical, in order to make sure
> that older maintenance tracks could benefit, and I do give updates for
> older maintenance tracks when able (but no promises).
> ...
> One cycle of major release development is expected to last between 8 to 10
> weeks, so keeping two stale maintenance tracks in addition to the latest
> maintenance track alive would roughly translate to 6 months shelf life for
> an ancient release.
Having said all that, I am starting to doubt what the point of all
this is.
Maybe I am being slow to come to this realization after having done this
for all these years, but Git is not like the Linux kernel, where hundreds
of companies maintain their own internal forks, e.g. out of tree drivers,
filesystem tweaks or scheduler tweaks, all tied to a specific version of
the internal API that is a rapidly moving target and cannot afford to
adjust to the bleeding edge. Also our strict no regression policy means
that it is not like an option --foo in one version of Git changes its
meaning from X to Y across version boundaries, and even if on rare
occasions we need to introduce incompatibilities to improve the system, we
give enough advance warning and execute careful migration plans to ensure
that third-parties can keep up, and the "fix at the oldest branch and
merge upwards" policy means fixes to important bugs will be in all the
maintenance tracks, including the 'master' version.
So in practical terms, once 1.7.9 is out, there is *no* practical reason
for anybody to use 1.7.8.x or anything older. The only two things people
are gaining by sticking to an older version are that (1) they do not have
a way to use new features, and that (2) they get fixes that are less
rigorously tested, because the testing happens mostly in the context of
the 'next' branch and then subsequently in the 'master' branch, and fixes
cooked in these two contexts may have unintended consequences that will
never be discovered until they are merged down to the older maintenance
tracks.
If we only released the feature releases without _any_ maintenance
releases, distros no longer have an excuse to stick to older maintenance
tracks ("For the upcoming Zesty Zebra LTS, Git will stay at 1.7.7.x and
never updated to any newer major version.") This in turn removes the need
for the third-party tools that support wider Git ecosystem to worry about
their users who are kept on very stale versions of Git by distros, because
any reasonably maintained distro will not pin their users to an ancient
version of Git. If we can change the distro's idea of what constitutes a
release of Git that is on a single maintenance track from the current
"1.7.7.3 and newer, but not anything that does not begin with 1.7.7." to
"1.7.9 and newer, but not anything that does not begin with 1.7.", that
would be a major win, I would imagine.
And dropping the maintenance tracks for older major releases may be a good
first step in that right direction.
With that in mind, the real answer to the original question in this thread
may be "the oldest supported version is the current one. stay at the
latest major release, in other words, do not even ask that question".
Thoughts?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html