as you have probably noticed we would like to update Rails framework to the latest version (4.1) when it's released.
The biggest task for us in this change is the update of Minitest to version 5. This would require test suites
of many gems that depends on Minitest to be fixed.
Here are the most significant changes of Minitest 5 taken from the changelog:
* 12 major (oft incompatible) changes:
* Renamed MiniTest to Minitest. Your pinkies will thank me. (aliased to MiniTest)
* Removed MiniTest::Unit entirely. No more manager objects.
* Added Minitest::Runnable. Everything minitest can run subclasses this.
* Renamed MiniTest::Unit::TestCase to Minitest::Test (subclassing Runnable).
* Added Minitest::Benchmark.
* Your benchmarks need to move to their own subclass.
* Benchmarks using the spec DSL have to have "Bench" somewhere in their describe.
* MiniTest::Unit.after_tests moved to Minitest.after_tests
* MiniTest::Unit.autorun is now Minitest.autorun. Just require minitest/autorun pls.
* Removed ParallelEach#grep since it isn't used anywhere.
* Renamed Runnable#__name__ to Runnable#name (but uses @NAME internally).
* Runnable#run needs to return self. Allows for swapping of results as needed.
That means the minimal changes needed to be done for every minitest test suite include:
* rename MiniTest::Unit::TestCase to Minitest::Test
* change require 'minitest/unit' (or 'test/unit') to require 'minitest/autorun'
* delete MiniTest::Unit.autorun (or use Minitest.autorun)
For some really simple test suites that might be enough. Look at the changes done in Rails 4.1
or in my own little gem for how the necessary changes may look like. For the others some additional
changes might be required.
Another problem are gems that depends on Gem::TestCase (like RubyGems plugins)
since Gem::TestCase is inherited from MiniTest::Unit::TestCase. I guess this can't be easily
solved at the moment, but we probably don't have many gems like that, or are we?
So what do you think of this change? Should we address it by updating upstream test suites?
Do you know about other issues that this can cause and I forgot to mention?
This Thursday March 20 (tomorrow that is :) ), after the Infrastructure
meeting (18:00-19:00 UTC) we are gonna hijack on #fedora-admin and hold
an unofficial meeting on GitLab, since many folks have expressed
interest on its current status in Fedora/EPEL.
Sytse Sijbrandij, co-founder of GitLab, will be there as well to discuss
the potential of deploying GitLab in Fedora or Red Hat infrastructure.
It would be cool if guys from Fedora infra team or anyone inside Red Hat
could attend (cc'ing some of you that reached me).
Sorry for the late notice, I've been somewhat busy lately, if someone
cannot make it we can always arrange to meet next week as well.
So see you tomorrow on #fedora-admin at 19:00 UTC.
FAS : axilleas
GPG : 0xABF99BE5
We would like to update RoR in Fedora to the RoR 4.1, which are close to
release. Sorry for the late notice.
-------- Původní zpráva --------
Předmět: F21 System Wide Change: Ruby on Rails 4.1
Datum: Tue, 18 Mar 2014 10:43:49 +0100
Od: Jaroslav Reznik <jreznik(a)redhat.com>
Přeposláno - Komu: devel(a)lists.fedoraproject.org
Společnost: Red Hat, Inc.
= Proposed System Wide Change: Ruby on Rails 4.1 =
Change owner(s): Vít Ondruch <vondruch(a)redhat.com>, Josef Stříbný
Ruby on Rails 4.1 is the latest version of well know web framework written in
== Detailed Description ==
The Ruby on Rails stack is evolving quickly and Fedora needs to keep pace with
it. Therefore the whole Ruby on Rails stack should be updated from 4.0 in
Fedora 20 to 4.1 (latest version) in Fedora 21. This will ensure that all the
Ruby developers using Fedora have the latest and greatest RPM-packaged Ruby on
== Scope ==
* Proposal owners:
** The whole Rails stack has to be updated
** Some dependencies of the Rails stack will need update
For the list of packages that need to be created/updated, see the Change Page.
* Other developers: Update Rails dependent packages to be working with Ruby on
* Release engineering: Not needed.
* Policies and guidelines: Not needed
devel-announce mailing list
Dne 13.3.2014 10:43, Jaroslav Reznik napsal(a):
> ----- Original Message -----
>> = Proposed System Wide Change: Ruby 2.1 =
>> Change owner(s): Vít Ondruch <vondruch(a)redhat.com>
>> Ruby 2.1 is the latest stable version of Ruby, with major increases in speed,
>> memory efficiency and reliability. With this major update from Ruby 2.0.0 in
>> Fedora 20 to Ruby 2.1 in Fedora 21, alongside JRuby, Fedora becomes the
>> superior Ruby development platform.
> This Change was approved by FESCo on yesterdays meeting with a note: "this
> requires a mini-mass rebuild for native ruby extensions so schedule needs
> to account for that".
Just for the record, bellow is the list of packages (147) which will
need rebuild, obtained using:
$ repoquery --disablerepo=* --enablerepo=rawhide
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' |
sort | uniq
The rubygem-* packages will need some changes, which you can apply by:
Let me know if you'd prefer to do the rebuild yourself, otherwise I'll
rebuild your package.
But prior the rebuild happens, I need to submit updated guidelines to
FPC and I'll try to ask rel-eng for side tag, so this probably won't
start sooner than 24th of March (date change reserved ;).
I know that both result to the same thing (if I remember correctly I had
asked Vit about this in IRC), but I have forgotten their real difference.
My attention got caught by a comment Josef made in one of his reviews
, saying that rubygem-foo is the new syntax. If that's the case, I
would like to propose 2 changes:
a) A reference in the wiki
b) An implementation for gem2rpm
I guess b) could be fairly easy by changing the templates.
By starting with these steps, there will be a push to use the new syntax
from now on. What do you think?
FAS : axilleas
GPG : 0xABF99BE5