1. 5
  1. 6

    Awesome. It’s really frustrating to have distros package outdated versions of software, because then people use it. For example, note that they’re removing Rails 3.0, which the rails team has effectively not supported for a long time now, and officially not supported for a few weeks. Also, I’m looking at you, Mac OSX: still bundling Ruby 1.8.7. Ugh.

    1. 1

      With bundler, I’m not sure it makes sense for anyone to ever package themselves.

      1. 3

        We still package a bunch of Gems on OpenBSD that require compilation because it lets us properly add package dependencies, like installing a mysql gem (via package) installs the mysql-client libraries, or RMagick installs ImageMagick and its millions of image library dependencies. We can also make sure that the Gem compilation has the proper CFLAGS and LDFLAGS to link to the proper libraries.

        Try searching for instructions on installing RMagick and Mysql gems on Mac OS X to see how difficult and annoying this is otherwise.

    2. 3

      I hope these recent security problems in Rails will prompt some discussion among the Rails core about a stable branch. In my opinion as a developer that uses Rails, as a system administrator that has to keep those apps up, and as an OpenBSD developer that has some say in Ruby packages and ok’d this removal of Rails packages, Rails is moving too quickly and making it difficult to maintain stable apps that stick around for years without any changes (aside from security updates or minor bugfixes in the framework).

      I had a Rails app in production that was at an earlier 3.2 version. I had to scramble to upgrade it to 3.2.11 when the security announcements came out and in the process, some shit broke (something to do with jquery-rails). It was a minor version bump in my framework and I just wanted the security fixes, but there were a bunch of other changes that broke my app. Why is my application development framework changing so much underneath my application?

      My older 2.3 apps were much easier to upgrade because they’ve been on the same Rails version (2.3.14) for over a year and I knew the only changes coming in .15 and .16 were those small security fixes. As a developer and a sysadmin, I look at that and wonder whether I should keep those apps at 2.3 going forward. If I do, I know I won’t have to worry about breaking things in future updates, but on the other hand, I don’t know how long the Rails developers will continue supporting 2.3. That is the confidence that is currently lacking and much needed.

      The Asterisk PBX is currently at version 11.2.1, yet Digium still maintains a separate “long term support” branch that is only at version since it only gets bug and security fixes. PHP does something similar with two concurrent branches, as does the Linux kernel. OpenBSD doesn’t but we rarely make such drastic changes that make it difficult to upgrade (and we also have the security record to not require that everyone keep up with us by only 6 months).

      I’d like to see the Rails core pick a version, even if it’s version 4 or whatever’s coming out next, and say, “this is the new stable branch, whatever we come out with in this version will solidify things for a long while, and we’ll support it for a long time coming”. They can still do the development they’re doing now and continue to release new versions that they use in their own shiny new apps, but for the rest of us that just want stability, we can know that this stable branch will stay that way for a long time. No Ruby version requirement changes, no added functionality, no Gem version dependency changes, no jQuery upgrades, nothing. Just release it and maintain it. Yes it will get stale and encourage methods of development that aren’t popular next week, but it will be able to power a bunch of apps that aren’t going to change for a long time.

      If that happened, I think it would greatly increase confidence among developers that they can learn that branch and use it for a long time coming. Ops people can know they won’t have to keep up with tons of version churn and when a security release comes out, they’ll know it has a very low probability of breaking anything. Book authors can publish books and teachers can write lessons knowing their stuff won’t be outdated in 6 months. I’d even contribute to this stable branch maintenance as long as the core decided on what to put in it and where to branch it from. I’d take the time to upgrade my 2.3 apps to it, and I’d most likely write new apps on it. Rails might even make it back into the OpenBSD ports tree if other packages like Redmine use that stable branch and those gems don’t need constant updates.

      1. 2

        Did you see our recent stability commitment with regards to supported versions?

        1. 2

          I hadn’t, but I just found it (you guys should really put this stuff front and center on rubyonrails.org, not tucked away in mailing list postings).

          So basically 3.2 is no longer getting active development and will only get bug fixes. Is it going to be maintained for a long time or just until 4.1 comes out pushing 4.0 to the new stable branch?

          1. 2

            you guys should really put this stuff front and center on rubyonrails.org, not tucked away in mailing list postings

            I agree, I brought this up.

            Is it going to be maintained for a long time or just until 4.1 comes out pushing 4.0 to the new stable branch?

            Depends on how you define ‘maintained.’ It will continue to receive security fixes, but that’s all. Bug fixes will go to master (which will be 4.1) and 4-0-stable. It will continue to get those security fixes until Rails 4.2.

            1. 2

              Right, so 3.2 isn’t really the “stable branch” that I was ranting about, it’s just “the last version that we’ll backport fixes to”. I’m assuming the website documentation will be for 4.0, not 3.2, new users will be encouraged to use 4.0, not 3.2, 3rd party gems will focus on 4.0, etc.

              The time between 2.3(.2) and 3.0.0 was only about a year, between 3.0.0 and 3.1.0 almost exactly a year, between 3.1.0 and 3.2.0 only about 6 months, and 3.2.0 and 4.0 I’m assuming will be about a year. Assuming a year between major releases, that means that 3.2 will stop getting bug fixes in about a year from now (when 4.1 comes out), and only security fixes for another year after that.

              edit: I should probably stop calling this a “stable branch”, since 3.2 is technically the stable branch… I suppose “long term support” branch is more what I’m getting at.

              1. 2

                Right. I’m not suggesting that we have what you want, just making sure that what we do do is clear, and that now, we’ve committed to something.

                3-2-stable is the stable branch. Might be easiest to just say that. :) But yes, LTS is more of what you’re talking about.