How long until OBS factory builds make it into LEAP

I have tried searching around the SuSe website, but I cannot find any clear answer to this, I just end up following a rats-nest of links to other links, none of which give a clear answer to timelines.

To keep it simple:

How long until I see SA 3.4.2 in LEAP15 ?

Not in the present Leap 15.0 I assume. When stable and in time for 15.1 and when enduring the integrated testing of 15.1, it will be in 15.1.

In a released versions of Leap, only security (and recommended) patches (often backported) will be offered, no new versions of products.

A simplified development path for openSUSE and SUSE ( SLE ):

  • Upstream -> Tumbleweed ( Factory, openQA tested )
  • Tumbleweed -> next SLE
  • next SLE -> next Leap

Thanks for the replies.

From my reading of the SuSe website, I sort of got to the understanding of the process stages listed by @Knurpht.

However, much like the answer from @Knurpht, nobody ever seems to give a timeframe, even an average one ? It would be nice to know if we’re likely talking weeks, months or years here before I see 3.4.2 in LEAP because that impacts my decision on whether to use SuSe at all for this application, because the "old’ version of SA potentially has a few issues on it.

Well, there is some sort of time frame: Leap package versions will stick to the version in the distro, apart from bug- and security fixes. I.e. no newer KDE, Apache etc. But, if you are really in need of a certain version, you can add it’s repo ( do not use home:/ or devel:/ repos ) and use the package from that repo. Another option you have is to run Tumbleweed, which currently serves 3.4.2 builds. Be careful, do not add Tw repos to your Leap install.

And, here it comes again :smiley: :
https://i.imgur.com/TDNNw4G.png

And, please be aware that both SUSE and openSUSE exist, but are not the same. SUSE Linux Enterprise ( a.k.a. SLE ) is the (paid) enterprise version.

Am slightly confused by this.

Following the LEAP15 links from https://en.opensuse.org/Package_repositories, I can only see the older SA builds ?

I also can’t see any obvious repo links from https://build.opensuse.org/request/show/637098 ? If I click on the repo tab (https://build.opensuse.org/repositories/openSUSE:Factory/spamassassin) and follow the links, it only seems to take me to Tumbleweed repos, which are obviously not the right thing.

Regarding your other comment:

It was my understanding Tumbleweed was not recommended for production use ?

https://software.opensuse.org/package/spamassassin , [noparse]devel:languages:perl has 3.4.2 [/noparse]

FWIW: I do use TW for production use, albeit only for my own work/production use, and have been doing so without issues for a couple of years now. At the time I needed some newer versions of some packages, which were all in TW and would have caused addition of half a dozen repos on Leap.
In your case I might add the repo, install the newer version, then disable the added repo. Moving to TW for just one piece of software maybe is a bit too much.

Now you’re confusing me. I thought you said not to use devel repos ?

Or I guess you’re saying the answer is to do what you said later, enable the devel and then disable it.

Also slightly confused but, for further info: the “devel: languages: Perl:” build status of the Apache Spamassassin version 3.4.3 released on September 16th 2018 is, for the Leap 15.0 case, “succeeded”: <https://build.opensuse.org/package/show/devel%3Alanguages%3Aperl/spamassassin>.

  • Given the source of the Spamassassin – the Apache Software Foundation – IMHO that build result can be interpreted as being “OK - reliable” …

But, as Knurpht has indicated, this isn’t true for all the builds in the “devel:” repository and therefore the “switch it on, and then switch it off” advice should avoid any nasty surprises with other packages …

I should have elaborated a bit more, given my previous replies. But that would have been what dcurtisfra already wrote. If it works as expected, indeed disable the repo.
Given the LTS strategy re. Leap, one sometimes has no other options.