openSUSE Leap 42.3 for Evergreen?

English Open Chat
1

3 observations:

  1. A new version of Leap is released every 12 months.
  2. Each Leap release is supported for 18 months from release.
  3. No Leap to date has enjoyed Evergreen support.

In effect, this forces openSUSE users to update their Leap version every year whether or not they want to. While regular updates may excite GNU/Linux enthusiasts, it comes at an unwelcome cost for more conservative users. It’s heartening to see an increasing number of `senior’ GNU/Linux newcomers to openSUSE, but forcing such users to start again from scratch every year (upgrades aren’t guaranteed to work and often break things!) would be an undesirable consequence of the current model. It’s also worth bearing in mind that no version of Microsoft Windows has ever enforced such a high frequency of version updates.

I therefore wish to propose that starting from Leap 42.3 (which is very stable), openSUSE reintroduces Evergreen support with a total of 36 months of support. The current lack of long-term support is a glaring omission from the Leap model and takes away an important choice enjoyed previously by openSUSE users. While dropping live-media and 32-bit are minor issues (both of which I actually support), dropping Evergreen is probably a step too far. What do the community think?

2

This is incorrect

A new service pack/minor version of Leap is released each calendar year, aligned with SUSE Enterprise. This can be longer (or shorter) than 12 months.

Each Leap service pack is supported until 6 months after the release of the next one for that current codestream.

Each leap major release is supported for several years

In otherwords, Leap 15.0s Release has no impact on 42.3s support life cycle which is currently expected to end on jan 31 2019.

The alignment with SLE service packs is important to realise.

All leap releases are dependant on suse for releasing the same maintenance updates for Leap that they do for SLE

SLE customers have a same lifecycle for service packs as Leap. They have the same expected pace for when to upgrade. But they pay for it.

Any suggestion that leaps lifecycle is extended beyond the lifecycle of SLE service will not have the support of SUSE. There is no way SUSE will provide for free to openSUSE more support than they provide to their own customers. That would be silly.

. While dropping live-media and 32-bit are minor issues (both of which I actually support), dropping Evergreen is probably a step too far. What do the community think?

Live media was not dropped.

Evergreen was dropped by the community due to lack of interest in the community. All of the evergreen maintainers quit because the Leap lifecycle fit what they wanted unlike the old openSUSE lifecycle.

I expect that lack of interest will remain the same, or the interest available will not be significantly high to motivate sufficient people to do for free the significant amount of work which even SUSE can’t justify for thier paying customers.

3

Also “forcing users to start from scratch”???

what planet are you on? We’ve had a fully supported process for in place upgrades between releases since like forever

4

I think you are looking at this wrongly. And I’ll note that Richard Brown has already given a detailed response.

Previously with openSUSE, each release has been new. And I have always done a clean install (keeping “/home” unchanged). But, with Leap it has been different. Each release of the 42.x series has been a continuation rather than a new release.

My tentative plans with Leap 15.x will be to upgrade in place. Yes, I’ll do clean test installs for testing. But on my regular systems, I’ll just update the repo list, and do a “zypper dup” to update in place. That seems to fit better. Of course a fresh install for 16.0 (or whatever the next series is called). But within the 15.x series, these are not really new releases as much as they are major updates.

5

I’ve always kept /home and did a new / install, and that worked well of course, but with post-install work, obviously. Reinstalling applications, setting shares, networking and so on.

Last year for the first time I did an in-place upgrade, from 42.2 to 42.3 in my backup desktop work machine. It was trouble free, with all repo-enabled applications also updated and keeping the same config. The result? I had a fully working machine in no more than a third of the time it takes to do a new install.

It is simply brilliant, and a tribute to SUSE/openSUSE developers. They are my real world heroes, really.

6

My usual, preferred method, as well.

However, like Neil, I keep some spare space where I first test-install the new version with its own /home to see what is happening and to hammer out any issues.

Once that is done, I do as above.

Last year for the first time I did an in-place upgrade, from 42.2 to 42.3 in my backup desktop work machine. It was trouble free, with all repo-enabled applications also updated and keeping the same config. The result? I had a fully working machine in no more than a third of the time it takes to do a new install.

Yes, I have also done this with some machines, usually trouble-free. I have recently upgraded a couple of machines from 42.3 to 15.0 this way, as well as other machines with the first method.

It is simply brilliant, and a tribute to SUSE/openSUSE developers. They are my real world heroes, really.

Yes, no kidding, hats off to their hard work.:slight_smile:

7

Perhaps the text in Portal:Leap - openSUSE Wiki should therefore be corrected since it seems to suggest quite clearly 18 months of support from release:

The latest release of openSUSE Leap, 15.0, was released on May 25, 2018. Leap will have minor releases and users are expected to upgrade to the latest minor release within 6 months of its availability, leading to a life cycle of 18 months of maintenance and security updates per minor release.

Thanks for the clarification concerning major/minor releases. I have used openSUSE since version 5.3 (i.e. S.u.S.E.), and have always appreciated the facility for incremental upgrades. Normally they have worked very well but unfortunately they are not without problems for reasons often outside the developers’ control (particularly in programming environments). As a result, except for laptops with a narrow range of computer applications, I always reinstall rather than upgrade.

Along with the other contributors to this thread, the planet I am on is one where the preferred method of updating the Leap version is by reinstallation rather than in-place upgrading even though we are well aware of the upgrade option. On this same planet it is also considered rude to reply to polite well-intentioned posts in an offensive and condescending manner.

8

It reads consistently to me. If I install version 15.X when it is first released, then I can expect 18 months of support (via security and maintenance patches). This is because 15.(x+1) will follow in ~12 months, and I have another 6 months before I’m expected to upgrade.

9

These are wiki pages, feel free to correct them where necessary

On this same planet it is also considered rude to reply to polite well-intentioned posts in an offensive and condescending manner.

And on this same planet lives me, who also feels annoyance at yet another accusation of “them” forcing users to do whatever, specially if that’s not true.

10

It was not an accusation, but an observation. But I apologise for suggesting that the Leap users are compelled to perform release updates every 12 months based on the following EOLs:

Leap 42.1 EOL 17th May 2017
Leap 42.2 EOL 27th Jan 2018
Leap 42.3 EOL 31st Jan 2019

I stand corrected: openSUSE Leap users are forced to perform release updates every 8-12 months.

Another observation: It is disappointing to see that an openSUSE forum administrator is willing to defend an offensive response to a polite and well-intended post.

11

Sorry, but nobody is forcing anyone to update Leap at any time.

So, quit spouting a falsehood.

Instead, they are being offered the opportunity to get improved versions – and supported fixes – if they so desire.

Anyone can continue using an older version of openSUSE as long as they wish. We do not travel around with weapons and point them at people’s heads to force them to update.

… mostly, because the travel would break our bank accounts.:stuck_out_tongue:

12

OK, let’s cool down a bit. I was a bit harsh, sorry for that.

But the reason Evergreen was dropped, is that the way Leap is built and released, upgrading to the future 15.x releases is by no means what 11.x -> 11.x+1 and so on were. They’re more like service pack. No major software upgrades f.e. That makes Leap 15 incl it’s .x releases have a lifetime like Evergreen had. That model was used for the 42.x releases too.
Another issue to have no Evergreen releases next to the Leap #.x releases, is that it’s an aweful lot of work to keep something alive in a world where changes are a daily phenomenon.

13

On 2018-07-08, Fraser Bell <Fraser_Bell@no-mx.forums.microfocus.com> wrote:
>
> flymail;2872841 Wrote:
>> I stand corrected: openSUSE Leap users are -forced- to
>> perform release updates every 8-12 months.
>
> Sorry, but nobody is forcing anyone to update Leap at any time.

Seriously? You are suggesting that imposing an EOL beyond which security updates and maintenance fixes are not longer
provided does not constitute a way of forcing responsible users to update? It’s impressive the way the openSUSE forum
comradery are able to close ranks, and culminate in a force to reckon with. However I have neither the time, energy, nor
desire to do so, and therefore regret ever proposing my suggestion albeit with the best of intentions.

14

Granted, some responses you got were a little over the line, IMHO, but coming to this conclusion is just getting silly.

As for your suggestion about an “Evergreen” version, one of the main reasons, if not the primary reason, is that there is nobody willing to do the enormous amount of work that would take. It needs more than one person (a team, actually), plus it needs hardware resources to accomplish.

As for the team for creation and continuing maintenance of such a thing, I see people asking now & then, but none of them – including you – have offered to step up and do the work.

… and that, my friend, is the bottom line of why there is none.

15

No worries. Upon rereading my posts, I hope you’d agree I kept my cool… perhaps a little too ice-cool. Unfortunately, there’s no mechanism to moderate the moderators!

I believe you. As RBrownSUSE has said, if such a level of support is not provided for paying SUSE users, then it cannot be expected for openSUSE users.

Maintaining packages is somewhat outside my brief. I’m an AI scientist, not a developer!

16

Yes, for some of us, becoming a developer is a huge mountain to climb, indeed.:wink:

17

Actually, we do this, as well. However, in some instances, we move a little slower and with more caution.

… though we tend to try to use caution in all instances with all users, which is why we work and co-ordinate as a team.

Because it is a team, we sometimes (actually, most often) wait until we receive responses from the rest of the Moderator team with their views before we act.

We try not to act too hastily, and we try desperately NOT to over-react. However, we too – believe it or not – are only human, and some of the OTHER MEMBERS of the Moderators’ Team occasionally make mistakes.

… Okay, doggonenationit, I make some mistakes, too.>:(

18

IMO
When Provisioners consider a distro for long term, Production use, they generally expect a 3 year window before a forced upgrade.

Technically,
I’m pretty sure that should mean that machines should run updates regularly for self-maintenance and minimal supervision for 3 years.

Based on the above,
Without reading various blogs and what-not, it was my personal assumption that releases such as 42.1, 42.2 and 42.3 should be considered major releases since you really had to “dup” from one to the next to maintain support.

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 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).

Still though,
As I’ve described… How openSUSE now defines its life cycle does not seem to be 100% consistent with what Purchasing and Zero-Touch SysAdmins expect.
Is it still OK that a “distro upgrade” is required every year plus?
Maybe.
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”

IMO,
TSU

19

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.

20

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.

Perhaps choose paid-for support with SLES instead?

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.

You can propose what you like - those that are involved with the development/support of the project ultimately get to make the decisions, and the move to the current model had buy-in from the majority of the community. There will always be pros and cons that may work for or against some use cases I guess.