This is currently in development, and even public API changes are not strictly ruled out. If you encounter problems, please report them on the bug tracker

Status: The main stack gems are at 1.2.0.pre1. It is possible to generate and run a basic application.

Current development:

• master: Only conversion to RSpec 2 and other "meta-changes" that are required in other branches.
• active_support: Migration from Extlib to ActiveSupport. Feature branch that will merge changes from master frequently.

The next release aims at using up to date and commonly available support libraries. At the moment, some core gems (merb-gen to name one) depend on Templater, which in turn depends on Extlib, which will not work well with anything using ActiveSupport. In the long run, moving to something else, e.g., Thor, would be advisable.

For the time being, you can get an updated Templater (reporting itself as 1.1.0) from a github fork. You can just put that repository into your Gemfile.

Merb is the last application still using Extlib, and we are moving over to ActiveSupport which is offering most things that Extlib can do, and then some more. The migration is done on the active_support branch. Right now, only merb-core and parts of merb-helper have been touched.

Applications built on merb need to make that migration as well, since Extlib and AS do not co-exist well. Most of the time, that will mean changing the string mangling functions to drop-in replacements, e.g., String#snake_case becomes String#underscore.

Minimal functionality of Extlib remains in merb-core in merb-core/core_ext, but consider those parts as private API.

One major impact is with merb-helpers, which will be using locale files from rails-i18n, which are available for a number of languages. To make use of them, place a copy of the locale definitions you need in your application, and add them to the load path. A plain "en" locale and an "undecorated" C locale are provided.

• Do not use Merb.root_path anymore, use Merb.root instead. It now takes the same parameters as .root_path did before.
• Merb.root= now sets Merb::Config[:merb_root] (and Merb.root is an accessor for that config entry).
• Removed the following deprecated methods:
  • Kernel#dependency, Kernel#dependencies: removed in favour of Bundler
  • Merb.orm_generator_scope: use the orm accessor instead
  • Merb.test_framework_generator_scope: use the test_framework accessor instead

• The public_dir_for helper will not default to / anymore when path lookup fails.

The merb binary will now default to thin instead of Mongrel, since the latter does not work properly with Ruby 1.9.

merb-gen is migrating over to Thor which will lead to some changes in calling conventions.

• merb-action-args is simple enough to become part of merb-core. Note however that its full functionality is only available on the 1.8.7 MRI and JRuby. Positional parameters are broken on other VMs like Rubinius or MRI 1.9.x.
• CSRF protection should be integrated; the details need to be determined.

They are gone. At this point, maintaining two sets of specs while trying to move forward is just too much work.

Current status: the specs for the "core" repository should pass on MRI 1.8.7 and 1.9.2, as well as recent Rubinius releases.

Yes, they do. However, this is in most cases because the specs themselves are broken. Bringing them up to speed will be a combined effort to fix both the specs and the Merb API.

Many spec failures that show up when running the rake task are produced because the execution model is different. The old rake task ran each spec file in its own process, while the new one bunches them all together into one process. Since Merb itself is not reentrant (a lot of state is kept in global constants), the specs will "poison" the process more and more, and fail because of that.

In good news however, merb-core now comes with a working .rspec file so you can use the "rspec" executable directly. To achieve process separation on Un*x-y systems, you can run something like:

# Use spec/private for the private specs
find spec/public/ -name "*_spec.rb" | xargs -P3 -L1 ruby1.9.1 -S rspec

which runs all private and many of the public specs, and there are currently very few failures. Change the -P parameter to a number of parallel processes suitable for your system, and use the Ruby implementation of your choice.