On 2014-04-27, Michał Lesiak <[email protected]> wrote: > Hi Ingo, > > On Sun, Apr 27, 2014 at 12:33 PM, Ingo Schwarze <[email protected]> wrote: > >> That's not a good plan at all. Sometimes, new binaries work on >> old versions and vice versa, but in general, that's not the case. >> So if you ship packages for 5.2-stable (well, actually, 5.2-obsolete), >> you force your users to use 5.2-obsolete. Not so great. >> >> For example, if one of your users chooses to run 5.5 (which would >> be a good idea), your 5.2 packages will *not* run on that at all. > > Ok, got it. My understanding was that binaries complied on older systems have > a > better chance of running correctly on newer systems than the other way around. > It's all about limiting a number of build machines, nothing else.
Taking the specific example of 5.5, we switched the types of time_t, ino_t, clock_t, and several members of struct kevent, so the chance of old binaries running are very low. If it's something where others can distribute source/packages, then probably better to work with porters to get it into the ports tree instead (this also means nothing to worry about for signed packages in 5.5/-current). If you're talking about some software where you want to restrict the redistribution then probably the best way is to install a number of VMs for the last couple of releases and build them there. If it's perl-only then you might get away with a few shortcuts, though would still need to watch out for the varying perl versions. .
