From: deletethis@invalid.lan   
      
   On Mon, 03 Nov 2025 06:35:52 +0000, Henrik Carlqvist wrote:   
      
   > considered stable by upstream providers, but the newer versions might   
   > not be backwards compatible with all the configuration files that you   
   > have.   
   >   
      
   That's why we have  major.minor.patch_level version releases of programs,   
   It's not unheard of Pat releasing new major.minors of programs into   
   "stable" releases.   
      
   > An example of an upstream provider with rather short release cycles is   
   > samba.   
      
   Samba, php, theres problably dozens more with life cycles of sub 2 years,   
   although php as of this year is gone back to supporting 3 years.   
      
   > Slackware 15.0 shiped with samba version 4.15.5 which back then was the   
   > current stable release of samba. A little more than a month later the   
   > 4.15 series of Samba went from "latest stable" to "maintenance mode".   
   > 2022-09-13 the 4.15 series of samba went to "security fixes only" and   
   > 2023-03-08 the 4.15 series was EOL.   
   >   
      
      
   4.15 was released in 2021, 2 year cycle, normal, the fact other key   
   daemons go longer for  major.minor.x doesnt mean all should, but 2 years   
   is usually fair. Also, last version was earlier, our samba mirror shows:   
   samba-4.15.13.tar.gz        2022-12-16 02:08   18M   
      
   > It seems as if the 4.18 series of samba was rather backwards compatible   
   > with 4.15 as it was provided as patches to Slackware 15.0, but the 4.22   
   > series of samba has instead been provided in /extra for Slackware 15.0.   
   >   
      
   On our internal file server I'm running   
   # smbd -V   
   Version 4.22.6   
      
   ls -la /etc/samba/smb.conf   
   -rw-r--r-- 1 root root 7118 Dec 10  2020 /etc/samba/smb.conf   
      
   IOW, our config is 5 years last time it was edited, and I'm sure that was   
   just adding s share so the config used here was probably written quite   
   some time before that with no changes (YMMV as I recall a recent   
   incompatability change if using active directory).   
      
   > Was it because of some library requirement from PCI DSS that you had to   
   > upgrade to current?   
   >   
      
   several libs, and dont get started on php, which is what sparked the   
   audit and then we discovered number of libs that failed also (if we didnt   
   have to audit php, we'd never have found out about the libs) usually this   
   has not been a problem in the past because we'd get new releases well   
   before things like that went EOL.  php 8.2 ends all support, including   
   security, in a months time, so we now have to re-eval what we are going   
   to do, we tried 8.4 and it built, but did cause some conflicts - this   
   was  back in February, now its up to 8.4.14 I'm hoping that will be   
   fixed, so we'll check that again, but that means the guys working over   
   Christmas will be busy one way or another.   
      
   postfix also failed, couldnt build the latest versions on 14.2 - (we dont   
   use Pat's version either even since he replaced sendmail in 15.0 as we   
   have specific build requirements), have been using postfix since 2008   
   when we moved to it from qmail/vpopmail setup we'd run for years before.   
      
      
      
   Cheers   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)