[OpenIndiana-discuss] How many versions of libs/apps should OI provide?

[Alexander Pyhalov]

Hi, Jim.

On 12/22/16 03:22 AM, Jim Klimov wrote:
>
>  We had a sort of a discussion on IRC today, which ended up in a choice better made or at least discussed by community than by the back-alley dealers ;)
>
>  So, as software evolution marches on, some projects' newer releases bring new features, bugs and ABI/API incompatibilities that make them different from older releases - and sometimes not backwards compatible (most projects try to make updates easy for their consumers, some don't).
>
>  As a result, the distro, such as OI/Hipster (and especially Hipster, posing as bleeding-edge rolling-release), has to balance and make a choice between:
>
>  a) providing only the newest versions of libs/apps (accept PRs that integrate a new version and remove old ones);
>
>  b) also provide older releases at least partially (e.g. libs that can be runtime-linked against by older binaries - especially if new ABI is not backwards-compatible and/or shared-library's SONAME numbers changed; or even headers, pkgconfig snippets, etc. that can be built against from source - especially if APIs changed), at least in cases where someone (distro maintainers, PR authors) believe that lack of old files can be an issue for end-users - but note that moving forward is often not an issue for binaries, if the ABIs were declared well and kept compatible by upstream sources;
>
>  c) don't rush for newest releases - ain't broke don't fix; backport CVE fixes to existing old-version recipes and be reluctant against new unknown bugs in new developments; perhaps try to stay on par with software versions delivered by stable releases of other distros like Debian, RHEL/CentOS or FreeBSD (which often considerably lag behind bleeding-edge as well) and pick up their security and bug fixes ;)
>

I'd like to separate libraries and applications.
In general case we want to provide only latest version of application if 
we can.
There are several classes of exceptions, however. These are databases 
(when storage format changes between major releases), translators (when 
language can significantly change between releases). and some 
applications with significant changes in configuration and ABI for 
third-party modules (like apache 2.2 and 2.4). Did I miss something here?

As for libraries, I'd go from consumers. I'd be reluctant to add library 
just to have it. If we add library without consumers, we even can't be 
sure that it actually works as expected. With consumers we can at least 
consider that it works for this consumer. So, I'd consider applications 
first-class citizens, not libraries.
When do we need to add new major version of some library? If we look 
from this point of view - only when some application requires this or, 
perhaps, when existing library has significant issues which cannot be 
fixed without updating to new major version.

Now, what can we do when we decided to bump library to new major 
version? First of all, I'd consider if all in-gate consumers can be 
switched to new version. If they can't, we should ship several versions 
so that both of them can be used (good examples are gtk2/gtk3, bad 
examples - libevent/libevent-2 - these needed significant patches to 
coexist). Let's consider, all oi-userland consumers can be switched to 
new version.

In this case we have a lot of question - do we ship old version or drop 
it? Do we ship just old binaries or all files (headers,pkgconfig), 
necessary for development? If we preserve old library, when are we going 
to drop it?

I don't have good answers on these questions. So far I've checked if 
some library is rather wide used (for example in SFE). If it's not, I'd 
rather drop old version and introduce flag day.

I suppose these answers are closely related to having releases and 
guaranteed stable API/ABI. So, that we can guarantee that this ABI is 
not broken before next major release... Damn, it doesn't work with 
Hipster, as it means we'll have not only support one stable release, but 
several branches of stable releases.... OK, next idea... This ABI is 
preserved for several next releases/snapshots.... Seems more real in 
current situation, but for how many snapshots should we keep some 
libraries? What libraries should be protected by such guarantees? I'd be 
reluctant to give such guarantees for mate/gnome libraries. In theory we 
could give such guarantees for some Xorg libraries, but not all... What 
about other?  Can we create transparent rules, which objects are 
protected by ABI-compatibility-guarantees and for how long?
Can we do it without having /stable ?
-- 
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department