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

[Francis.D]

Hi all

For my part,
I prefer to have a stable version of software. If it's necessary to wait 3
months more why not. OI may be certainly  on rolling release model and
opting only on stable version software.

As the Oi developer team is small, it would be wise to adopt stability in
order to avoid compatibility problems.

just my small opinion

best regard

2016-12-22 6:01 GMT-05:00 Till Wegmüller <toasterson at gmail.com>:

> Hello Everyone
>
>
> Am 22.12.2016 um 10:44 schrieb Alexander Pyhalov:
>
>> 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?
>>
>
> I very much agree with the Seperation of Libraries and applications.
> Libraries are part of the applications. Some Applications require the same
> parts an thus they are shared. Which makes sense. Now here comes the magic
> of modern Package management Systems. In pip for example (python) you name
> the version of the dependency you have. When all Dependencies that need to
> installed are computed you end up with the most moden version still
> compatible with your requirements.
>
> I would suggest we don't have two or more versions in Userland but have
> them available in the hipster IPS repo, so that IPS can work its magic if a
> Application needs an older version.
>
> Generaly having the most up to date version of Applications is the best
> solution. A good example why would be xscreensaver. The author works with
> only one version where he fixes bugs and add features. When something
> brakes you tell him that and he fixes it. So why not help his efforts and
> work togheter with him? This not only helps the developer but also us. When
> we make the authors aware of us and help them make their software run on
> our systems and help fix bugs we found, we become both first class citizens
> of each other. Reducing Workload on our side even further as we don't have
> to constantly port.
>
> > 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?
>
> As for stability what are the guaranties from Upstream Developers? How can
> a small team of develpers offer more than the Upstream developer? Most of
> the times this question has been answered with using old versions. The
> logic being that what worked 10,000 times will work 10,001 times. But is
> that really true? When using SLES in my previous work I had more than once
> the Problem that Patches from SUSE broke more than Upstream Linux. Simply
> because SUSE had less developers that could See those Problems. We have
> even less developers. So the Development modell that upstream uses can help
> more than whatever effort we make.
> I would suggest a wiki page where we keep track of the Major Application
> stacks we use and what they offer for guaranties and if we would recomend
> them for usage based on experience. (Packaging and Software using it). I
> bet that Upstream dev will like to see how their work is perceived aswell.
>
>
> Greetings
> Till
>
>
> _______________________________________________
> openindiana-discuss mailing list
> openindiana-discuss at openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>