Issue #16895 has been updated by rubyFeedback (robert heiler). As I got older (it has been almost 20 years now since I have been using ruby, and I feel physically older too compared to the more young-version of me back in the days), my focus has shifted a bit. I was super-experimental when I was younger. Nowadays I try to stay with stable ruby releases whenever possible. So the xmas-release is usually when I switch; I do tend to switch as quickly as possible, to avoid any legacy-drag that we had from e. g. ruby 1.8.x to 1.9.x to 2.x and beyond. I am kind of like "an early adopter of stable ruby", if that makes sense. :D I can still find some issues here and there and report it. Testing unstable is a bit of an issue and hassle, though. I wrote a lot of ruby scripts over the years, and ruby is used to maintain my whole linux system (I compile from source whenever possible); so getting the new git release of ruby is as simple as doing "ry ruby --gitty" for me. That will download the latest git sources, re-package them into .tar.xz and put it into $SRC_DIR/ruby/. I can even automatically compile it too. So this is actually the simple part. The bigger issue is time investment, and forgetting it. I kind of adjusted mentally to be lazy, so I download the latest ruby on xmas and then keep on using it, until the next xmas. So I rarely get to test new features, unless they are interesting. I don't have a good alternative model. Would be interesting if we could have ruby so modular that there be tons of ruby dialects, and we could test each dialect in the "middle of the year", just recompiling parts of ruby that would be affected (e. g. like when pattern matching was added. Imagine if we could have a toggle for all of ruby behaviour, a bit like we can specify the linux kernel). ---------------------------------------- Misc #16895: Request for cooperation: Try your applications/libraries with master branch and debug options https://bugs.ruby-lang.org/issues/16895#change-101823 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal ---------------------------------------- ## Summary If you maintain a Ruby application or library, please consider testing with the Ruby `master` branch, including the *debug* build. This should be in addition to testing with all supported stable releases of Ruby. To make this easier, we are providing Docker images and GitHub actions, as outlined below. ## Details The rapid pace of Ruby development sometimes introduces bugs, such as incorrect behaviour or unexpected incompatibilities. Despite our best efforts and testing, without your feedback, we cannot catch every issue. Understanding how our changes impact downstream code is important feedback for the Ruby core developers. We want to know how your applications work on master. If you encounter an error when testing with the `master` branch (e.g. `[BUG] ...` in output log), [please report it](https://bugs.ruby-lang.org). It will be very helpful. ### Testing With `master` Testing using the `master` branch (sometimes referred to as `ruby-head`) will make your Ruby scripts ready for the next Ruby version. It also helps us catch incompatibilities as we change and evolve Ruby's public interface. ### Testing With Debug Build Testing with the master branch debug build enables many assertions within the Ruby interpreter. These assertions can detect incorrect usage of the C extensions, and also bugs in the interpreter when running your program. These assertions have an impact on the performance of the interpreter. To compile a debug build, refer the later section titled "Building With Debug Mode". ## Continuous Integration With `master` Building Ruby for your own testing environment can be difficult, so we are providing two convenient ways to use the master branch in your existing testing pipeline: - Docker Images - Github Action ### Docker Images The [rubylang docker repository](https://hub.docker.com/r/rubylang/ruby) provides images for various Ruby versions, including nightly builds of master with and without debug assertions" - Nightly built master: `rubylang/ruby:master-nightly-bionic` - Nightly debug built master: `rubylang/ruby:master-debug-nightly-bionic` Here is an example `Dockerfile`: ```dockerfile FROM rubylang/ruby:master-nightly-bionic ``` Then to build: ```shell $ docker build . Sending build context to Docker daemon 2.048kB Step 1/1 : FROM rubylang/ruby:master-nightly-bionic master-nightly-bionic: Pulling from rubylang/ruby ... Status: Downloaded newer image for rubylang/ruby:master-nightly-bionic ---> 059d367a8fbd Successfully built 059d367a8fbd ``` ### GitHub Action The [GitHub Action to setup Ruby](https://github.com/ruby/setup-ruby) provides both `ruby-head` and `ruby-debug` builds. Here is an example workflow to test on all Ruby stable releases, including `ruby-head` and `ruby-debug`: ```yaml name: Development on: [push] jobs: test: strategy: fail-fast: false matrix: os: [ubuntu] ruby: [2.5, 2.6, 2.7, head, debug] runs-on: ${{ matrix.os }}-latest continue-on-error: ${{ matrix.ruby == 'head' || matrix.ruby == 'debug' }} steps: - uses: actions/checkout@v2 - uses: ruby/setup-ruby@v1 with: ruby-version: ${{ matrix.ruby }} - run: bundle install - run: bundle exec rake ``` See the [documentation](https://github.com/marketplace/actions/setup-ruby-jruby-and-truffleruby) for more details on how to use this action. ## Building With Debug Mode To create a debug build of Ruby, execute the following commands: ``` $ git clone https://github.com/ruby/ruby.git $ cd ruby $ autoconf $ cppflags=-DRUBY_DEBUG=1 ./configure --prefix=$HOME/.rubies/ruby-debug $ make install ``` If you are using `chruby`, you can switch to the above build: ``` $ chruby ruby-debug ``` You can find more details to build Ruby master in the [README](https://github.com/ruby/ruby/blob/master/README.md#how-to-compile-and-instal...). ## Acknowledgement We thank @mrkn for the Docker image, @eregon for the GitHub Action, and @ioquatix for reviewing this announcement. -- https://bugs.ruby-lang.org/