[Umlaut-general] Umlaut 3.0 goes beta and other Umlaut announcements

Jonathan Rochkind rochkind at jhu.edu
Thu Mar 22 19:24:17 UTC 2012


I've tagged an 3.0.0beta1 release of Umlaut, it's looking good enough to 
call it beta.

I am proceeding with local testing. Still getting my production server 
set up, but once I do I'm going to have a two week period where I ask 
staff to test. If all goes well, and any problems found are fixed, I'm 
going to switch my production Umlaut to 3.0 for a scheduled 3-hour 
window. Again, look at error logs or any error reports, if all goes well 
or any problems are fixed, I'll switch to Umlaut 3.0 in production here.

At that point or soon after, I'll probably tag the final 3.0.0 release.

But I would LOVE it if I could get some other beta testers before then, 
installing it, configuring it for your local needs, etc., reporting any 

I am also not sure if Scot's Aleph/Primo services are functioning 
properly in 3.0, I'm unable to test them myself, talk to Scot about that 
-- or try to test em yourself if you've got Aleph or Primo (but again, 
if you have trouble, Scot would be the one to talk to).  I would love it 
if we could have this confirmed for sure before a final release, but I'm 
not going to let it hold up the release if nobody's got time for it.

Also, Scot, if you have particular customization needs related to things 
you are doing in Umlaut 2.x, but will need to re-do differently in 
umlaut 3.x, I'd love to hear about it, and make sure Umlaut 3.x meets 
your needs before final release. But I'm not going to block on it, and 
we can always change things up after the 3.0.0 final release too if 
needed, although I'm going to try really hard to make no backwards 
incompatible changes at that point.


Umlaut's always done some slightly unconventional things with 
multi-threading and Rails ActiveRecord. It's a bit klunky, but it works, 
and was the best I could come up with for Umlaut's needs.

But there's some indication that future Rails 4 will be changing it's 
multi-threaded support in ways that will make things even more 
challenging for Umlaut.

I'm not entirely sure what we'll do then; I've got a variety of possible 
ideas, not sure which will be easiest/best. Certainly what Umlaut does 
now is not the best way it could be doing things anyway, but it's been 
good enough so far. Perhaps by the time Rails 4 comes out (within the 
next year though I think?) the available options (or my thinking on 
them) will have changed to make the path forward obvious. At any rate, 
I'm confident I can find something feasible to do that keeps Umlaut at 
least working as well as it does now (and it seems to mostly work better 
in Rails 3.2 and ruby 1.9.3 than it had under Umlaut 2).


Umlaut 3.0 development has switched to a github hosted git, instead of 
the rubyforge svn.

After Umlaut 3.0 goes final, I'd like to actually get _rid_ of the 
rubyforge svn, to have one less thing to keep track of, and avoid 
mistaken forking of Umlaut.

There will be an umlaut 2.0 branch in the git repo. However, umlaut 2.x 
install and upgrade instructions kind of assume and depend on the svn 
being available. (As Umlaut was not a gem then; Umlaut 3.0 as a gem 
needs to assume no particular source repo for install/upgrade).  If the 
svn goes away, it would make installing umlaut 2.x difficult (which i'm 
not too concerned about, why would anyone install umlaut 2.x at that 
point?), but may also make maintaining/upgrading existing umlaut 2.x 
installs difficult.

Which could be a problem for people with existing umlaut 2.x installs 
who are not able to find time to upgrade to 3.x.  I'm not sure. Feedback 
from such people welcome.

At some point soonish I'd also like to retire this rubyforge-hosted 
mailing list, and probably move to a Google Groups hosted list.  The 
rubyforge list has been a bit of a problem (for some reason Dale @ 
Vanderbilt can't get emails from it), and in general I'd like to just 
leave rubyforge behind. I haven't found a better alternative than Google 
Groups, although sadly Google Groups gives you no way to import your 
existing archives. Feedback on this plan welcome too.

More information about the Umlaut-general mailing list