On Fri, Apr 21, 2023 at 11:35:46AM +0200, Carlos E. R. wrote:

On 2023-04-21 10:26, Erik Skultety wrote:

...

Hi, first of all, if this list is not the right one for this kind of request, please point me to the right direction where it would be.

I'd like to request adding a 'latest' or even '15' (any major release version) named symlink to the HTTP OS tree [1] as both to be consistent in how Leap containers are tagged [2] as well as helping other projects/consumers e.g. libosinfo [3] or our libvirt-ci [4] tool etc. to always conveniently track the latest minor release of Leap. The use case of most of these upstream communities is to always consume the latest contents to find regressions and compatibility issues early, and it poses some (not completely negligible) burden for all these communities to manually flip all URLs to flip the Leap release they track to the latest minor when it's released. So, I'm kindly asking whether such a thing could be considered.

How about

https://download.opensuse.org/distribution/openSUSE-current/

or

https://download.opensuse.org/distribution/openSUSE-stable/

?

Both point to 15.4 currently.

What happens with these when Leap 16 is out? Are both going to be flipped to 16? The thing that I didn't mention is that the major version matters just as much. So, even if 16 is out, the latest 15.X is likely going to be supported for a while, so we should be still able to get the latest 15 conveniently (for CI purposes many projects actually test against more than just a single release - the stable supported ones), but I assume those links would already be pointing to to 16.X by that time, so we're again in this same situation we're in right now. Regards, Erik

On Fri, Apr 21, 2023 at 12:22:04PM +0200, Carlos E. R. wrote:

On 2023-04-21 12:17, Erik Skultety wrote:

...

On Fri, Apr 21, 2023 at 11:35:46AM +0200, Carlos E. R. wrote:

...

On 2023-04-21 10:26, Erik Skultety wrote:

...

Hi, first of all, if this list is not the right one for this kind of request, please point me to the right direction where it would be.

I'd like to request adding a 'latest' or even '15' (any major release version) named symlink to the HTTP OS tree [1] as both to be consistent in how Leap containers are tagged [2] as well as helping other projects/consumers e.g. libosinfo [3] or our libvirt-ci [4] tool etc. to always conveniently track the latest minor release of Leap. The use case of most of these upstream communities is to always consume the latest contents to find regressions and compatibility issues early, and it poses some (not completely negligible) burden for all these communities to manually flip all URLs to flip the Leap release they track to the latest minor when it's released. So, I'm kindly asking whether such a thing could be considered.

How about

https://download.opensuse.org/distribution/openSUSE-current/

or

https://download.opensuse.org/distribution/openSUSE-stable/

?

Both point to 15.4 currently.

What happens with these when Leap 16 is out?

There is not going to be Leap 16.

I don't know what there will be, but something very different. Not upgradeable, I think. Should have a different name.

That's not the point though. The point is there's going to be something and I'm curious what the expected outcome in terms of the URLs or distro vendor support for the current release might be in that case? Ultimately that is the reason why I even asked for the 'latest' symlinks in the first place. Regards, Erik

On Fri, Apr 21, 2023 at 12:44:37PM +0200, Carlos E. R. wrote:

On 2023-04-21 12:28, Erik Skultety wrote:

...

On Fri, Apr 21, 2023 at 12:22:04PM +0200, Carlos E. R. wrote:

...

On 2023-04-21 12:17, Erik Skultety wrote:

...

On Fri, Apr 21, 2023 at 11:35:46AM +0200, Carlos E. R. wrote:

...

On 2023-04-21 10:26, Erik Skultety wrote:

...

Hi, first of all, if this list is not the right one for this kind of request, please point me to the right direction where it would be.

I'd like to request adding a 'latest' or even '15' (any major release version) named symlink to the HTTP OS tree [1] as both to be consistent in how Leap containers are tagged [2] as well as helping other projects/consumers e.g. libosinfo [3] or our libvirt-ci [4] tool etc. to always conveniently track the latest minor release of Leap. The use case of most of these upstream communities is to always consume the latest contents to find regressions and compatibility issues early, and it poses some (not completely negligible) burden for all these communities to manually flip all URLs to flip the Leap release they track to the latest minor when it's released. So, I'm kindly asking whether such a thing could be considered.

How about

https://download.opensuse.org/distribution/openSUSE-current/

or

https://download.opensuse.org/distribution/openSUSE-stable/

?

Both point to 15.4 currently.

What happens with these when Leap 16 is out?

There is not going to be Leap 16.

I don't know what there will be, but something very different. Not upgradeable, I think. Should have a different name.

That's not the point though. The point is there's going to be something and I'm curious what the expected outcome in terms of the URLs or distro vendor support for the current release might be in that case? Ultimately that is the reason why I even asked for the 'latest' symlinks in the first place.

AFAIK it is impossible to decide what to do if it is not known what distro will be there and how will it be upgraded and what servers it needs. Maybe it doesn't use repos at all.

Certainly nothing a link change can handle.

It is impossible, AFAIK, to upgrade a 15.5 Leap machine to whatever come next. Not viable to add a link to the server.

Why are you adding upgrades into the mix? The fact that you're always able to track the latest minor release of any major version with a given link is irrelevant to upgrades, IOW, CI systems are more often than not set up in a way where in case of containers you just specify "from <registry>/leap:15" and it'll give you the latest 15.minor there is. When the next big thing arrives, unless vendor drops support for Leap 15, the 15 tag isn't going anywhere and it'll point to the latest 15.minor there is. Why can't there be the same thing for install trees? That way anyone consuming Leap 15 in their CI will always refresh to whatever contents is the latest for Leap 15. Now, let's say hypotheticaly there would be Leap 16. That CI system would either decide to drop 15 completely, but if that release is still supported by the vendor, than the more likely scenario is to add another entry and another instance for Leap 16, keeping 15 fresh. This is very much relevant for VM workloads and installs. I mean if you look at Alma for example, they track RHEL releases, but they only ever expose the latest RHEL minor for a given Alma major. I get it, OpenSUSE has a different process, different policy, but so far IMO I haven't been given a compelling reason why the idea of having a symlink in the tree is bad, because like I hopefully explained, that's something which, although a thing, is mostly irrelevant to existence of such a link in the first place.

The people going from 15.5 to whatever comes next have to read a lot of documentation (that doesn't exist yet) and install fresh something new in some way yet to be invented.

Okay, point taken, but again, ^this IMO doesn't have a practical impact on what I'm requesting, IOW if one uses the links for things that aren't supported it's their problem. Unless you're trying to tell me that upgrades among minor versions are either not seamless or not supported at all, i.e. going from 15.4 to 15.5 which would ultimately be enough of a justification to me not to do what I'm asking and we're basically done here, because so far I considered your upgrade argument to only relate to going to the next major release. Erik

On Fri, Apr 21, 2023 at 02:21:28PM +0200, Carlos E. R. wrote:

On 2023-04-21 14:00, Erik Skultety wrote:

...

On Fri, Apr 21, 2023 at 12:44:37PM +0200, Carlos E. R. wrote:

...

On 2023-04-21 12:28, Erik Skultety wrote:

...

On Fri, Apr 21, 2023 at 12:22:04PM +0200, Carlos E. R. wrote:

...

On 2023-04-21 12:17, Erik Skultety wrote:

...

On Fri, Apr 21, 2023 at 11:35:46AM +0200, Carlos E. R. wrote: > On 2023-04-21 10:26, Erik Skultety wrote: > > > > Hi, > > first of all, if this list is not the right one for this kind of request, > > please point me to the right direction where it would be. > > > > I'd like to request adding a 'latest' or even '15' (any major release version) > > named symlink to the HTTP OS tree [1] as both to be consistent in how Leap > > containers are tagged [2] as well as helping other projects/consumers e.g. > > libosinfo [3] or our libvirt-ci [4] tool etc. to always conveniently track the > > latest minor release of Leap. The use case of most of these upstream > > communities is to always consume the latest contents to find regressions and > > compatibility issues early, and it poses some (not completely negligible) > > burden for all these communities to manually flip all URLs to flip the Leap > > release they track to the latest minor when it's released. So, I'm kindly > > asking whether such a thing could be considered. > > How about > > https://download.opensuse.org/distribution/openSUSE-current/ > > or > > https://download.opensuse.org/distribution/openSUSE-stable/ > > ? > > > Both point to 15.4 currently.

What happens with these when Leap 16 is out?

There is not going to be Leap 16.

I don't know what there will be, but something very different. Not upgradeable, I think. Should have a different name.

That's not the point though. The point is there's going to be something and I'm curious what the expected outcome in terms of the URLs or distro vendor support for the current release might be in that case? Ultimately that is the reason why I even asked for the 'latest' symlinks in the first place.

AFAIK it is impossible to decide what to do if it is not known what distro will be there and how will it be upgraded and what servers it needs. Maybe it doesn't use repos at all.

Certainly nothing a link change can handle.

It is impossible, AFAIK, to upgrade a 15.5 Leap machine to whatever come next. Not viable to add a link to the server.

Why are you adding upgrades into the mix? The fact that you're always able to track the latest minor release of any major version with a given link is irrelevant to upgrades, IOW, CI systems are more often than not set up in a way where in case of containers you just specify "from <registry>/leap:15" and it'll give you the latest 15.minor there is. When the next big thing arrives, unless vendor drops support for Leap 15, the 15 tag isn't going anywhere and it'll point to the latest 15.minor there is. Why can't there be the same thing for install trees? That way anyone consuming Leap 15 in their CI will always refresh to whatever contents is the latest for Leap 15. Now, let's say hypotheticaly there would be Leap 16. That CI system would either decide to drop 15 completely, but if that release is still supported by the vendor, than the more likely scenario is to add another entry and another instance for Leap 16, keeping 15 fresh. This is very much relevant for VM workloads and installs. I mean if you look at Alma for example, they track RHEL releases, but they only ever expose the latest RHEL minor for a given Alma major. I get it, OpenSUSE has a different process, different policy, but so far IMO I haven't been given a compelling reason why the idea of having a symlink in the tree is bad, because like I hopefully explained, that's something which, although a thing, is mostly irrelevant to existence of such a link in the first place.

...

The people going from 15.5 to whatever comes next have to read a lot of documentation (that doesn't exist yet) and install fresh something new in some way yet to be invented.

Okay, point taken, but again, ^this IMO doesn't have a practical impact on what I'm requesting, IOW if one uses the links for things that aren't supported it's their problem. Unless you're trying to tell me that upgrades among minor versions are either not seamless or not supported at all, i.e. going from 15.4 to 15.5 which would ultimately be enough of a justification to me not to do what I'm asking and we're basically done here, because so far I considered your upgrade argument to only relate to going to the next major release.

The link to 15.5 will appear when 15.5 becomes released and final.

The link to 16 or whatever is next will have to be decided when they know what it will be, how it will be published, etc. Nobody knows what it will be, so it is not possible to decide "yes, we'll put a link", or "no, there will not be a link because it is something totally new and unrelated to 15 and will use a new tree".

I'm sorry, but ^this doesn't make sense at all. There's always going to be a URL to every major release's resource tree as long the vendor is going to continue shipping ISOs, which I doubt they're going to stop. Whether there's going to be an OS install tree (aka kernel and ramdisk) that's a different question, but it's still irrelevant to having a 'latest' link. What I imagine having is this: https://download.opensuse.org/distribution/leap: - leap 15.4 - leap 15.5 - leap 15.X # (X > 5) - leap 15 -> leap 15.X - ... https://download.opensuse.org/distribution/<whatever>: - whatever 1.0 - whatever 1 -> whatever 1.0 So I'd like to get an answer on whether ^this is feasible or not. The existence of another next future distro is completely irrelevant to the above, so I'm looking for answers with real technical challenges preventing the above, something like: - yes, we may consider this to support the community - no, we can't do this ,because upgrades between minor versions are not seamless or not supported at all - no, because our internal CI and release processes are so complex, that adding a seemingly trivial symlink like that would pose a serious change to our code or process I'm simply finding it hard to accept that just the sole idea of a future distro we know nothing about could, in terms of adding a few symlink entries, really impact either what we have today or that it would be such a game changer that no OS tree URLs would be involved in distributing this new thing which I'm sure won't be the case. Erik

On Fri, Apr 21, 2023 at 08:56:16AM -0400, Neal Gompa wrote:

On Fri, Apr 21, 2023 at 8:51 AM Erik Skultety wrote:

...

On Fri, Apr 21, 2023 at 02:21:28PM +0200, Carlos E. R. wrote:

...

On 2023-04-21 14:00, Erik Skultety wrote:

...

On Fri, Apr 21, 2023 at 12:44:37PM +0200, Carlos E. R. wrote:

...

On 2023-04-21 12:28, Erik Skultety wrote:

...

On Fri, Apr 21, 2023 at 12:22:04PM +0200, Carlos E. R. wrote: > On 2023-04-21 12:17, Erik Skultety wrote: > > On Fri, Apr 21, 2023 at 11:35:46AM +0200, Carlos E. R. wrote: > > > On 2023-04-21 10:26, Erik Skultety wrote: > > > > > > > > Hi, > > > > first of all, if this list is not the right one for this kind of request, > > > > please point me to the right direction where it would be. > > > > > > > > I'd like to request adding a 'latest' or even '15' (any major release version) > > > > named symlink to the HTTP OS tree [1] as both to be consistent in how Leap > > > > containers are tagged [2] as well as helping other projects/consumers e.g. > > > > libosinfo [3] or our libvirt-ci [4] tool etc. to always conveniently track the > > > > latest minor release of Leap. The use case of most of these upstream > > > > communities is to always consume the latest contents to find regressions and > > > > compatibility issues early, and it poses some (not completely negligible) > > > > burden for all these communities to manually flip all URLs to flip the Leap > > > > release they track to the latest minor when it's released. So, I'm kindly > > > > asking whether such a thing could be considered. > > > > > > How about > > > > > > https://download.opensuse.org/distribution/openSUSE-current/ > > > > > > or > > > > > > https://download.opensuse.org/distribution/openSUSE-stable/ > > > > > > ? > > > > > > > > > Both point to 15.4 currently. > > > > What happens with these when Leap 16 is out? > > There is not going to be Leap 16. > > I don't know what there will be, but something very different. Not > upgradeable, I think. Should have a different name.

That's not the point though. The point is there's going to be something and I'm curious what the expected outcome in terms of the URLs or distro vendor support for the current release might be in that case? Ultimately that is the reason why I even asked for the 'latest' symlinks in the first place.

AFAIK it is impossible to decide what to do if it is not known what distro will be there and how will it be upgraded and what servers it needs. Maybe it doesn't use repos at all.

Certainly nothing a link change can handle.

It is impossible, AFAIK, to upgrade a 15.5 Leap machine to whatever come next. Not viable to add a link to the server.

Why are you adding upgrades into the mix? The fact that you're always able to track the latest minor release of any major version with a given link is irrelevant to upgrades, IOW, CI systems are more often than not set up in a way where in case of containers you just specify "from <registry>/leap:15" and it'll give you the latest 15.minor there is. When the next big thing arrives, unless vendor drops support for Leap 15, the 15 tag isn't going anywhere and it'll point to the latest 15.minor there is. Why can't there be the same thing for install trees? That way anyone consuming Leap 15 in their CI will always refresh to whatever contents is the latest for Leap 15. Now, let's say hypotheticaly there would be Leap 16. That CI system would either decide to drop 15 completely, but if that release is still supported by the vendor, than the more likely scenario is to add another entry and another instance for Leap 16, keeping 15 fresh. This is very much relevant for VM workloads and installs. I mean if you look at Alma for example, they track RHEL releases, but they only ever expose the latest RHEL minor for a given Alma major. I get it, OpenSUSE has a different process, different policy, but so far IMO I haven't been given a compelling reason why the idea of having a symlink in the tree is bad, because like I hopefully explained, that's something which, although a thing, is mostly irrelevant to existence of such a link in the first place.

...

The people going from 15.5 to whatever comes next have to read a lot of documentation (that doesn't exist yet) and install fresh something new in some way yet to be invented.

Okay, point taken, but again, ^this IMO doesn't have a practical impact on what I'm requesting, IOW if one uses the links for things that aren't supported it's their problem. Unless you're trying to tell me that upgrades among minor versions are either not seamless or not supported at all, i.e. going from 15.4 to 15.5 which would ultimately be enough of a justification to me not to do what I'm asking and we're basically done here, because so far I considered your upgrade argument to only relate to going to the next major release.

The link to 15.5 will appear when 15.5 becomes released and final.

The link to 16 or whatever is next will have to be decided when they know what it will be, how it will be published, etc. Nobody knows what it will be, so it is not possible to decide "yes, we'll put a link", or "no, there will not be a link because it is something totally new and unrelated to 15 and will use a new tree".

I'm sorry, but ^this doesn't make sense at all. There's always going to be a URL to every major release's resource tree as long the vendor is going to continue shipping ISOs, which I doubt they're going to stop. Whether there's going to be an OS install tree (aka kernel and ramdisk) that's a different question, but it's still irrelevant to having a 'latest' link. What I imagine having is this:

https://download.opensuse.org/distribution/leap: - leap 15.4 - leap 15.5 - leap 15.X # (X > 5) - leap 15 -> leap 15.X - ...

https://download.opensuse.org/distribution/<whatever>: - whatever 1.0 - whatever 1 -> whatever 1.0

So I'd like to get an answer on whether ^this is feasible or not. The existence of another next future distro is completely irrelevant to the above, so I'm looking for answers with real technical challenges preventing the above, something like: - yes, we may consider this to support the community - no, we can't do this ,because upgrades between minor versions are not seamless or not supported at all - no, because our internal CI and release processes are so complex, that adding a seemingly trivial symlink like that would pose a serious change to our code or process

I'm simply finding it hard to accept that just the sole idea of a future distro we know nothing about could, in terms of adding a few symlink entries, really impact either what we have today or that it would be such a game changer that no OS tree URLs would be involved in distributing this new thing which I'm sure won't be the case.

For what it's worth, I think your request is pretty reasonable. We do support upgrading across minor versions, but nobody has asked for this before that I recall.

Could you please send a request to admin@opensuse.org outlining your specific needs and what benefit it would have for you? The Heroes team[1] can then look into enabling this.

[1]: https://en.opensuse.org/openSUSE:Heroes

Sweet. Thank you Neal, appreciated. I will send the request and let's see what the outcome is :). Erik

Let me review the symlink situation and meaning, I would say that this falls to my responsibilities. Lubos On Fri, 2023-04-21 at 20:58 +0200, Christian Boltz wrote:

Hello,

Am Freitag, 21. April 2023, 15:04:36 CEST schrieb Erik Skultety:

...

On Fri, Apr 21, 2023 at 08:56:16AM -0400, Neal Gompa wrote:

...

...

For what it's worth, I think your request is pretty reasonable. We do support upgrading across minor versions, but nobody has asked for this before that I recall.

Could you please send a request to admin@opensuse.org outlining your specific needs and what benefit it would have for you? The Heroes team[1] can then look into enabling this.

[1]: https://en.opensuse.org/openSUSE:Heroes

Sweet. Thank you Neal, appreciated. I will send the request and let's see what the outcome is :).

Sorry to send you to yet another place, but...

I'm afraid the heroes will tell you that we make sure the server runs, but don't manage the "current" symlinks ourself ;-)  [1]

These symlinks are updated by the release manager. For example,the task for 15.5 is at https://progress.opensuse.org/issues/114295 This also means you better ask the release manager ;-) (now in CC) [If you send a request to admin@, it's not a completely lost case - we can assign it to Lubos.]

So far, we "only" have the "current" symlinks that point to the latest release, and change them even if the major version changes. IIRC you are the first who asks for a $major symlink. That would be a bit additional work, but sounds doable.

An interesting question is: what should happen with the symlinks if a major version is EOL. When the last 15.x release goes EOL, what should we do with the "15" symlink? Keep it pointing to the EOL release? Delete it? Something else?

Regards,

Christian Boltz

[1] Exceptions might apply. For example if the release manager forgets     to update one of the "current" symlinks, the heroes could fix it.

On Fri, Apr 21, 2023 at 2:58 PM Christian Boltz wrote:

Hello,

Am Freitag, 21. April 2023, 15:04:36 CEST schrieb Erik Skultety:

...

On Fri, Apr 21, 2023 at 08:56:16AM -0400, Neal Gompa wrote:

...

...

For what it's worth, I think your request is pretty reasonable. We do support upgrading across minor versions, but nobody has asked for this before that I recall.

Could you please send a request to admin@opensuse.org outlining your specific needs and what benefit it would have for you? The Heroes team[1] can then look into enabling this.

[1]: https://en.opensuse.org/openSUSE:Heroes

Sweet. Thank you Neal, appreciated. I will send the request and let's see what the outcome is :).

Sorry to send you to yet another place, but...

I'm afraid the heroes will tell you that we make sure the server runs, but don't manage the "current" symlinks ourself ;-) [1]

These symlinks are updated by the release manager. For example,the task for 15.5 is at https://progress.opensuse.org/issues/114295 This also means you better ask the release manager ;-) (now in CC) [If you send a request to admin@, it's not a completely lost case - we can assign it to Lubos.]

So far, we "only" have the "current" symlinks that point to the latest release, and change them even if the major version changes. IIRC you are the first who asks for a $major symlink. That would be a bit additional work, but sounds doable.

An interesting question is: what should happen with the symlinks if a major version is EOL. When the last 15.x release goes EOL, what should we do with the "15" symlink? Keep it pointing to the EOL release? Delete it? Something else?

Leave it be pointing to the latest EOL release. At that point the 15 series is EOL. For 16 series, we'd have a "16" symlink that would move with the minor versions. -- 真実はいつも一つ！/ Always, there's only one truth!

On 4/21/23 19:52, Carlos E. R. wrote:

On 2023-04-21 12:17, Erik Skultety wrote:

...

On Fri, Apr 21, 2023 at 11:35:46AM +0200, Carlos E. R. wrote:

...

On 2023-04-21 10:26, Erik Skultety wrote:

...

Hi, first of all, if this list is not the right one for this kind of request, please point me to the right direction where it would be.

I'd like to request adding a 'latest' or even '15' (any major release version) named symlink to the HTTP OS tree [1] as both to be consistent in how Leap containers are tagged [2] as well as helping other projects/consumers e.g. libosinfo [3] or our libvirt-ci [4] tool etc. to always conveniently track the latest minor release of Leap. The use case of most of these upstream communities is to always consume the latest contents to find regressions and compatibility issues early, and it poses some (not completely negligible) burden for all these communities to manually flip all URLs to flip the Leap release they track to the latest minor when it's released. So, I'm kindly asking whether such a thing could be considered.

How about

https://download.opensuse.org/distribution/openSUSE-current/

or

https://download.opensuse.org/distribution/openSUSE-stable/

?

Both point to 15.4 currently.

What happens with these when Leap 16 is out?

There is not going to be Leap 16.

I don't know what there will be, but something very different. Not upgradeable, I think. Should have a different name.

This is very much undecided yet, at this stage it is very much technically possible to do something that is upgradable and that is not very different and it is being investigated and will likely be worked on. But to answer the original question once Leap 16 is out (or even if it isn't and we have something else) Leap 15.5 will only continue to be supported for another 6 months and there won't be a 15.6, so it would make sense for stable to move to pointing to 16.0 in the same way it will move to 15.5 post its release. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Wed, Apr 26, 2023 at 7:10 AM Carlos E. R. wrote:

On 2023-04-26 04:30, Simon Lees wrote:

...

On 4/21/23 19:52, Carlos E. R. wrote:

...

On 2023-04-21 12:17, Erik Skultety wrote:

...

On Fri, Apr 21, 2023 at 11:35:46AM +0200, Carlos E. R. wrote:

...

On 2023-04-21 10:26, Erik Skultety wrote:

...

...

...

...

...

How about

https://download.opensuse.org/distribution/openSUSE-current/

or

https://download.opensuse.org/distribution/openSUSE-stable/

?

Both point to 15.4 currently.

What happens with these when Leap 16 is out?

There is not going to be Leap 16.

I don't know what there will be, but something very different. Not upgradeable, I think. Should have a different name.

This is very much undecided yet, at this stage it is very much technically possible to do something that is upgradable and that is not very different and it is being investigated and will likely be worked on.

But to answer the original question once Leap 16 is out (or even if it isn't and we have something else) Leap 15.5 will only continue to be supported for another 6 months and there won't be a 15.6, so it would make sense for stable to move to pointing to 16.0 in the same way it will move to 15.5 post its release.

My doubt hurdle is that people would be tempted to just do a "zypper dup" on that stable link without thinking much. There may be machines doing automated updates using that link.

If that isn't fine, we've done a bad job. -- 真実はいつも一つ！/ Always, there's only one truth!

On Wed, 2023-04-26 at 20:58 +0930, Simon Lees wrote:

On 4/26/23 20:44, Neal Gompa wrote:

...

On Wed, Apr 26, 2023 at 7:10 AM Carlos E. R. wrote:

...

On 2023-04-26 04:30, Simon Lees wrote:

...

On 4/21/23 19:52, Carlos E. R. wrote:

...

On 2023-04-21 12:17, Erik Skultety wrote:

...

On Fri, Apr 21, 2023 at 11:35:46AM +0200, Carlos E. R. wrote: > On 2023-04-21 10:26, Erik Skultety wrote: > >

...

...

...

> > How about > > https://download.opensuse.org/distribution/openSUSE-current/ > > or > > https://download.opensuse.org/distribution/openSUSE-stable/ > > ? > > > Both point to 15.4 currently.

What happens with these when Leap 16 is out?

There is not going to be Leap 16.

I don't know what there will be, but something very different. Not upgradeable, I think. Should have a different name.

This is very much undecided yet, at this stage it is very much technically possible to do something that is upgradable and that is not very different and it is being investigated and will likely be worked on.

But to answer the original question once Leap 16 is out (or even if it isn't and we have something else) Leap 15.5 will only continue to be supported for another 6 months and there won't be a 15.6, so it would make sense for stable to move to pointing to 16.0 in the same way it will move to 15.5 post its release.

My doubt hurdle is that people would be tempted to just do a "zypper dup" on that stable link without thinking much. There may be machines doing automated updates using that link.

If that isn't fine, we've done a bad job.

Yes, if we do end up with a more limited feature set I guess we will need to come up with a mechanism to remove no longer supported packages so that when people do zypper dup they can see the list of stuff that's gone away.

We would not fall to this trap if we'd have more predictable schedule for new major releases. We're already bit behind expectations so problem is even more visible.

-- Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek SUSE Linux                           Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B