Overview

Request 477529 declined

if we want to ship a newer ruby version it should be 2.4

Loading...

Leap Reviewbot's avatar

unhandled request type delete

unhandled request type delete

request needs review by release management


Ludwig Nussel's avatar

looks like ruby 2.2 is still maintained so seems little reason to drop it. In any case, dropping it needs to be documented in the release notes https://github.com/openSUSE/release-notes-openSUSE/blob/Leap_42.3/xml/release-notes.xml


Marcus Rueckert's avatar

yes it is still maintained but i dont want to maintain 4 ruby versions on a single distro. 2 is enough. unless more people step up to help with it. we will get 2.1 and 2.4.


Marcus Rueckert's avatar

JFYI: coolo has submitted 2.4 to factory. see SR#477708. I start to clarify why he thinks the package is not done yet. but from my side it looks good.


Ludwig Nussel's avatar

postpone until discussed


Ludwig Nussel's avatar

as agreed offline on Friday the state of ruby in 42.3 should be quickly discussed on the Factory list to see if going for 2.1&2.4 only is fine.


Ruediger Meier's avatar

Please don't remove it. From my experience ruby is highly incompatible between different versions. That's we would not need to include all versions but we should tell users to use rvm instead to install whatever they need locally. However, once we decided to ship a certain ruby version we should never remove it during Leap lifetime.


Marcus Rueckert's avatar

will you step up as a co maintainer? i already have people asking for 2.4 ... that would mean 4 ruby releases in parallel. for which i dont have the time.


Ruediger Meier's avatar

The users who want to have the newest ruby could use Tumbleweed or rvm. For the next major Leap you could only maintain one ruby version from the beginning.


Marcus Rueckert's avatar

JFYI even on SLES we deprecate and remove older versions of the same package. see postgresql for example. where we nowadays support 9.4


Ruediger Meier's avatar

I don't think that we would rename the postgresql binaries on upgrade or uprade if both versions would speak incompatible SQL language. Moreover postgresql upstream cares about backward compatible upgrades while scripting languages like ruby or python usually try to break as much as possible. That's obviously why we have all these ruby versions at all. Whyever you thought that ruby 2.2 was needed one year ago, these reasons are not gone, it's still needed. See, even upstream still maintains 2.2!

Personally I still need ruby 1.8 because we have unfortunately chosen to use whatever ruby CMS for our website. I've learned it the hard way and switched to rvm to get it still running. But I would not expect to have such a pain when simply following LTS distro minor updates.


Marcus Rueckert's avatar

we actually rename the binary as they are in a version subdirectory ... the only difference is we also maintain update-alternative links for them. but if you want to address a specific version of postgresql the paths are versioned.

and I think people submitted 2.2 2 years ago because it was the latest ruby version. and 2.3 was the latest last year. and now i have people bugging me for 2.4 because it is the latest now.

and ruby is relatively good at backwards compatibility as well. 1.8 -> 1.9/2.0 was the only really bad cut.


Ruediger Meier's avatar

Well and after 2.4 there will be another new version. Looks like Leap is not the right choice for them. As already said, they should use rvm or Tumbleweed. Just don't give them 2.4 in Leap. In Future you will only need to maintain two versions. One in TW (the latest) and one particular old one in Leap.


Marcus Rueckert's avatar

this statement is wrong on so many levels. but for now weekend.


Ruediger Meier's avatar

regarding "1.8 -> 1.9/2.0 was the only really bad cut"

I'd say, they did it once, they will do it again :) The next guy who wants to sell us a ruby website is already out of the race.

Request History
Marcus Rueckert's avatar

darix created request

if we want to ship a newer ruby version it should be 2.4


Leap Reviewbot's avatar

leaper added leap-reviewers as a reviewer


Leap Reviewbot's avatar

leaper accepted review

ok


Jimmy Berry's avatar

jberry_factory added openSUSE:Leap:42.3:Staging:A as a reviewer

Being evaluated by staging project "openSUSE:Leap:42.3:Staging:A"


Jimmy Berry's avatar

jberry_factory accepted review

Picked openSUSE:Leap:42.3:Staging:A


Yuchen Lin's avatar

maxlin_factory accepted review

Removing from openSUSE:Leap:42.3:Staging:A, re-evaluation needed


Yuchen Lin's avatar

maxlin_factory added factory-staging as a reviewer

Requesting new staging review


Jimmy Berry's avatar

jberry_factory added openSUSE:Leap:42.3:Staging:C as a reviewer

Being evaluated by staging project "openSUSE:Leap:42.3:Staging:C"


Jimmy Berry's avatar

jberry_factory accepted review

Picked openSUSE:Leap:42.3:Staging:C


Ludwig Nussel's avatar

lnussel_factory accepted review

Removing from openSUSE:Leap:42.3:Staging:C, re-evaluation needed


Ludwig Nussel's avatar

lnussel_factory added factory-staging as a reviewer

Requesting new staging review


Ludwig Nussel's avatar

lnussel accepted review

no discussion seen on Factory list. Furthermore there's now https://build.opensuse.org/package/view_file/openSUSE:Leap:42.3/lifecycle-data/openSUSE.lifecycle?expand=1 to mark things as deprecated.


Ludwig Nussel's avatar

lnussel_factory declined request

meant to decline

openSUSE Build Service is sponsored by