As always, Tsu makes some very valid and relevant points.
On 2018-07-13, tsu2 <tsu2@no-mx.forums.microfocus.com> wrote:
> But,
> Recently in another thread I was disabused of my assumption that 42.1,
> 42.2 and 42.3 were major releases…
> No, “42” is the major version and 42.1, 42.2 and 42.3 were each to be
> considered minor releases within the “42” major release cycle.
I agree that a three-year support major-release model is consistent with the perception of 42.1, 42.2, and 42.3 as
minor releases.
> I can accept that definition from a technical point of view because it’s
> easy to see that the core was relatively stable and unchanged through
> the entire “42” cycle, and it might even be possible to upgrade from
> openSUSE 13.2 to any of the “42” releases without too much risk
> (although to be perfectly safe, I’d always recommend what is in the SDB
> which is not to skip <any> release).
On simple systems with straightforward software package installations, I believe incremental openSUSE minor or major
release updates are very reliable so long as no release version is skipped. However, this reliability is cannot be
guaranteed on complex custom installations that include many third party packages - in such cases it is often more
time-efficient simply to reinstall rather than attempt an upgrade especially for system admins that have scripted the
entire installation process. For this reason it could be argued that the support time for openSUSE Leap is in reality
defined by its minor release cycle period rather than the major release cycle period.
> Is it still OK that a “distro upgrade” is required every year plus?
> Maybe.
I think it is OK, but it necessitates having to have a fallback GNU/Linux installation at hand, since the performance
cost of BTRFS not acceptable for some.
> Today I’m not in charge of any machines that have to run 3 years with
> little to no attention, even when I deploy a very large farm or cluster,
> it’s done for specific purpose for a specified amount of time and then
> destroyed (that’s why I use virtualization).
> I might feel differently if my requirements were more “Long Term
> Production”
Picture yourself as a system administrator on 1st May 2018: you have just acquired a new cluster and want to install
GNU/Linux. You look at openSUSE Leap and find that the latest release is 42.3 with an EOL of 31st January 2019. What do
you do? If you install Leap 42.3, you’re good for only 9 months, and some might find that unacceptable.
The problem is that the overlap of support time between major releases (i.e. 42 to 15) is identical to that of minor
releases (42.3 to 15.0). It could therefore be argued that distinction of major and minor releases as a way of claiming
a three-year support cycle is contrived and disingenuous. In this thread I proposed a workaround by extending support
for the final minor release according to the openSUSE Evergreen model. However, following the frankly hostile reaction
of senior members of the openSUSE community to my suggestion, I am reluctant to propose alternative solutions.