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

[Jim Klimov]

 Hello all,

 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 ;)

 All of these variants (and probably more can be thought of) have their valid pro's and contra's so it is not easy to pick one as an apparently best choice.

 One aspect is being "friendly" to software used by end-users, especially those who migrated from an existing Solarish installation and use (or start out with) software binaries not coming from our distro packages. For them, an appropriate SONAME of old libraries with old ABIs can be a good safe harbor while they decide to stick with it or update - to distro userland packages, or something else - but either way, on their own schedule. This is a conservative choice, an argument in favor of (b).

 Another aspect is being friendly to developers who want to directly work on, and port stuff to either OpenIndiana itself or just "something illumos/solaris-like", e.g. to verify portability during CI tests. These users would likely want or need either the latest versions of dependencies (argument for (a)), or a few versions of the latest releases in the projects' branches if several release trees are maintained on the upstream (argument for (a) and (b)).

 And there is a notion of having less bugs, which may be gained by following strategy (c)... but perhaps becoming less interesting and relevant day by day.

 As became clear from discussions (and history of PR reviews), the activists of the userland repo do have different opinions on this, and it is a good time to ask what the existing and potential users would prioritize? Do we have people who want their old bins to "just run"? Do we want people to use only (or mostly) the packages we provide in our ever-growing userland, or should we consider that someone might have rolled their own - and evicting older dependencies from our packages would upset their private existing builds? Do we have (existing, or a chance to catch) some migrant developers who want their shiny new code to build with the least friction and side quests to get the dependency ecosystem built first? Do we want stability if not stagnation in the rolling-bloody-release distro that many do use as production deployments? Or do we want a radical "always only everything new because upstreams deemed their stuff ready to release"? Or something in between to satisfy all of the above? :)

 Thanks for your valuable insights and opinions,
 Jim Klimov (and those other guys who hanged out on IRC tonight and asked me to move the discussion to ML ;) )