enola-rb 0.5.2 → 0.5.3

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: e11fd621c0938e8bf47d4fb4601db8dc659039437b1b10331babdc335e651810
-  data.tar.gz: e03a1e9510a0694f4e0a8f2f099b60642ab9207fd9752c1c098db15e75bb854a
+  metadata.gz: 21a0b2da8eadd5dab80d8bc5c984f8c25dbe25f0831ce95f6862727cfda0fe60
+  data.tar.gz: c4e5b90c53c0cf85533bef512987311e0676dc45a9de91f96d4a605360070fe8
 SHA512:
-  metadata.gz: 1dc77e4c5836a844d95dfea1118440efe3e861f2b3f20d938c9a0c312ae44f9fedc5e2b3e38fe3e0fdec4d07ec00c2fd881211ef485bfd7a19e8769ebaa95fbb
-  data.tar.gz: 4603af7245ee31b60fbce69619298235b9a167a03042632dd82fcec2faabc922e034b08ad2aeab048af32f396c016e24ba660873293d2ce4212def58dba7b5cd
+  metadata.gz: 9c2230831992ef3d41403c0c4feba1bfd04d2a06f8406c6afdb3db91a43dd699f244b100b7ff0f189b9df5b744e3b77fd2890c96ccea020e791725294baf138d
+  data.tar.gz: 020f83092617474cbaae18711b950e9ceb4beeebd1b37dfdb6b4d4f5fc8586a928c19b09c96dfcdd176d7a78d4a8d1756d6811808795fb39ddea847286bd2fe0

data/CHANGELOG.md

@@ -1,3 +1,20 @@
+## enola 0.5.3, enola-rb 0.5.3 and munola 0.6.0 (2026-08-24)
+
+Both providers are on again. enola-labs shipped the prefix walk fix in 0.4.6,
+which is the release the enola and enola-rb gems now drive, so the config they
+write carries Prism and Rubydex as it did before the hang was found.
+
+munola waits. Its binary is a fork release cut before that fix, so it stays on
+Prism alone until the channel is re-cut, and its version file says which
+upstream it is built on rather than implying the newest.
+
+munola-rb is gone, and was never published. The railtie and generator move
+into munola, which is why munola is 0.6.0: one gem for one channel, since the
+split that makes sense for enola and enola-rb, letting a Rubyist take the
+binary wrapper without the Rails layer, does not describe anyone's use of
+munola. Requiring munola still loads no Rails; the generator registers when
+the application has already loaded it.
+
 ## enola 0.5.2, enola-rb 0.5.2, munola 0.5.2 and munola-rb 0.5.2 (2026-08-23)
 
 Rubydex is off in the config these gems write, and named in a comment beside

data/README.md

@@ -4,10 +4,11 @@ Four pure-Ruby gems, one repository, for running
 [enola](https://github.com/enola-labs/enola), the architecture-graph tool,
 from Ruby. None of them carries a binary or compiles anything.
 
-Two channels, the same layering on both: `enola` wraps the released upstream
-binary and `enola-rb` adds the Rails layer on it; `munola` wraps the munola
-binary and `munola-rb` adds the Rails layer on that. The Rails code is written
-once, in `enola-rb`, and the munola gems add only what is munola's own.
+Two channels. `enola` wraps the released upstream binary and `enola-rb` adds
+the Rails layer on it, split so a Rubyist can take the wrapper without Rails.
+`munola` is one gem for its own channel, wrapper and Rails layer together,
+because nobody installs it to avoid Rails. The Rails code is written once, in
+`enola-rb`, and munola adds only what is munola's own.
 
 ## `enola`
 
@@ -109,14 +110,9 @@ publishes; `MUNOLA_BINARY=/path/to/enola` names one to drive instead, and
 every command says which answered. `munola` depends on `enola` at the same
 minor and on `enola-guides` 0.3.1 or later; requiring it loads no Rails.
 
-## `munola-rb`
+## munola under Rails
 
-The Rails layer over `munola`, what `enola-rb` is to `enola`. It depends on
-both at the same minor and adds one generator.
-
-```ruby
-gem "munola-rb"
-```
+munola carries its own generator, and the rake tasks are enola-rb's:
 
 ```sh
 bin/rails generate munola:install --tenant-column company_id
@@ -124,7 +120,8 @@ bin/rake enola:snapshot
 bin/rake enola:check
 ```
 
-The generator runs the same install `munola init` does. The rake tasks are
-enola-rb's and need no munola copy: `munola` installs its own resolver when it
-loads, so `enola:snapshot` and `enola:check` drive the munola binary in an app
-that has this gem, and the upstream binary in one that does not.
+The generator runs the same install `munola init` does. `munola` installs its
+own resolver when it loads, so `enola:snapshot` and `enola:check` drive the
+munola binary in an app that has this gem, and the upstream binary in one that
+does not. Requiring munola loads no Rails; the generator registers when the
+application has already loaded it.

data/lib/enola_rb/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module EnolaRb
-  VERSION = "0.5.2"
+  VERSION = "0.5.3"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: enola-rb
 version: !ruby/object:Gem::Version
-  version: 0.5.2
+  version: 0.5.3
 platform: ruby
 authors:
 - Muhamed Isabegovic
 autorequire:
 bindir: bin
 cert_chain: []
-date: 2026-08-23 00:00:00.000000000 Z
+date: 2026-08-24 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: enola
@@ -16,14 +16,14 @@ dependencies:
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 0.5.0
+        version: 0.5.3
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 0.5.0
+        version: 0.5.3
 - !ruby/object:Gem::Dependency
   name: enola-guides
   requirement: !ruby/object:Gem::Requirement