Version 0.0.5.

.travis.yml

@@ -3,26 +3,26 @@ rvm:
     - "1.9.3"
     - "2.0.0"
     - "2.1.2"
-    - "jruby-1.7.14"
+    - "jruby-1.7.15"
 env:
-    - FORTITUDE_SPECS_RAILS_VERSION=4.1.5
-    - FORTITUDE_SPECS_RAILS_VERSION=4.0.9
+    - FORTITUDE_SPECS_RAILS_VERSION=4.1.6
+    - FORTITUDE_SPECS_RAILS_VERSION=4.0.10
     - FORTITUDE_SPECS_RAILS_VERSION=3.2.19
     - FORTITUDE_SPECS_RAILS_VERSION=3.1.12
     - FORTITUDE_SPECS_RAILS_VERSION=3.0.20
-    - FORTITUDE_NATIVE_EXTENSIONS=false FORTITUDE_SPECS_RAILS_VERSION=4.1.5
+    - FORTITUDE_NATIVE_EXTENSIONS=false FORTITUDE_SPECS_RAILS_VERSION=4.1.6
     - FORTITUDE_NATIVE_EXTENSIONS=false FORTITUDE_SPECS_RAILS_VERSION=3.0.20
 before_script:
     - export JRUBY_OPTS="$JRUBY_OPTS -J-Xmx128m -J-Xms128m -J-Xss2048k"
 matrix:
     exclude:
         # Rails 4.x doesn't support Ruby 1.8.7
         -   rvm: 1.8.7
-            env: FORTITUDE_SPECS_RAILS_VERSION=4.1.5
+            env: FORTITUDE_SPECS_RAILS_VERSION=4.1.6
         -   rvm: 1.8.7
-            env: FORTITUDE_NATIVE_EXTENSIONS=false FORTITUDE_SPECS_RAILS_VERSION=4.1.5
+            env: FORTITUDE_NATIVE_EXTENSIONS=false FORTITUDE_SPECS_RAILS_VERSION=4.1.6
         -   rvm: 1.8.7
-            env: FORTITUDE_SPECS_RAILS_VERSION=4.0.9
+            env: FORTITUDE_SPECS_RAILS_VERSION=4.0.10
         # 2014-06-19 ageweke -- ARGH. After trying about seventeen different things, no matter what I do,
         # Travis fails JRuby builds about 20% of the time with "Killed". Their documentation indicates that this
         # is likely an out-of-memory issue (i.e., entire VM's memory is consumed). However, I'm running JRuby with
@@ -34,17 +34,17 @@ matrix:
         # one manually to make sure there aren't other failures, too. This is very frustrating, but I can't seem to
         # find a way around it. If there's a fix out there somewhere, I'm all ears!
     allow_failures:
-        -   rvm: jruby-1.7.12
-            env: FORTITUDE_SPECS_RAILS_VERSION=4.1.5
-        -   rvm: jruby-1.7.12
-            env: FORTITUDE_SPECS_RAILS_VERSION=4.0.9
-        -   rvm: jruby-1.7.12
+        -   rvm: jruby-1.7.15
+            env: FORTITUDE_SPECS_RAILS_VERSION=4.1.6
+        -   rvm: jruby-1.7.15
+            env: FORTITUDE_SPECS_RAILS_VERSION=4.0.10
+        -   rvm: jruby-1.7.15
             env: FORTITUDE_SPECS_RAILS_VERSION=3.2.19
-        -   rvm: jruby-1.7.12
+        -   rvm: jruby-1.7.15
             env: FORTITUDE_SPECS_RAILS_VERSION=3.1.12
-        -   rvm: jruby-1.7.12
+        -   rvm: jruby-1.7.15
             env: FORTITUDE_SPECS_RAILS_VERSION=3.0.20
-        -   rvm: jruby-1.7.12
-            env: FORTITUDE_NATIVE_EXTENSIONS=false FORTITUDE_SPECS_RAILS_VERSION=4.1.5
-        -   rvm: jruby-1.7.12
+        -   rvm: jruby-1.7.15
+            env: FORTITUDE_NATIVE_EXTENSIONS=false FORTITUDE_SPECS_RAILS_VERSION=4.1.6
+        -   rvm: jruby-1.7.15
             env: FORTITUDE_NATIVE_EXTENSIONS=false FORTITUDE_SPECS_RAILS_VERSION=3.0.20

CHANGES.md

@@ -1,5 +1,22 @@
 # Fortitude Releases
 
+## 0.0.5, 17 September 2014
+
+* You can now load both Fortitude and Erector at the same time into a project, and it will "just work": Erector
+  widgets will render using Erector, and Fortitude widgets will render using Fortitude. (Fortitude takes over the
+  actual template engine registration for `.rb` files, and uses a trick to keep Erector from displacing it; it then
+  looks at the widget class being rendered, and delegates all Erector rendering directly to Erector.)
+* Added `Fortitude::Widget.all_fortitude_superclasses`, which returns an `Array` of all superclasses of a widget up to,
+  but not including, `Fortitude::Widget` itself.
+* Added `Fortitude::Widget.widget_class_from_file`, which accepts the path to a file and an array of "root" directories
+  to look under (_i.e._, assuming you're using something like Rails' autoloading mechanism), and returns the `Class`
+  object for the widget that's contained in that file. This uses a series of mechansims to try to detect the class
+  that's present in the file: a "magic comment" that can be present in the file, an array of class names to try
+  that you can pass in, the position of the class in the file hierarchy, and scanning the source text itself.
+* Added a `record_tag_emission` class-level setting that tells a widget to call `#emitting_tag!` on the
+  `Fortitude::RenderingContext` when emitting a tag; you can use this to build various systems that need to know where
+  in the hierarchy of tags we are at the moment.
+
 ## 0.0.4, 24 June 2014
 
 * Added support for building a JRuby-specific gem to the gemspec, so that things work smoothly for JRuby users.

README-erector.md

@@ -18,7 +18,7 @@ garbage as ERb/Erubis);
 * Full, complete native HTML5 support (with selectable X/HTML4.01 Strict/Transitional/Frameset doctypes);
 * Enforces HTML element-nesting and attribute-name rules, and enforce ID uniqueness across a page (configurable, and off by default);
 * In development, beautiful HTML comments around each widget, showing what class is being rendered, the values of all variables supplied to that class, and the nesting depth of that widget;
-* Fully compatible with Ruby 1.8.7-2.1.x, JRuby 1.7.11, and Rails 3.0.x-4.1.x;
+* Fully compatible with Ruby 1.8.7-2.1.x, JRuby 1.7.15, and Rails 3.0.x-4.1.x;
 * Full Tilt support, and can be used with or without Rails;
 * Much more thorough Rails support — all known Rails integration points have been resolved, and it should work
 as smoothly with Rails as does (_e.g._) ERb/Erubis;

lib/fortitude/version.rb

@@ -1,3 +1,3 @@
 module Fortitude
-  VERSION = "0.0.4"
+  VERSION = "0.0.5"
 end