Approaching first beta of 1.0.0

1

Hey Everyone,

I’m thinking about releasing rom 1.0.0 beta in the upcoming weeks, assuming that we can finalize work on a couple of features and improvements. From my point of view ROM has become feature-rich enough, and robust enough too. There are some glitches in the setup, some confusing behaviors here and there, but nothing major that would require big changes, everything we know about can be easily improved, which I’ll be focusing on in the upcoming weeks with the goal to release first beta of 1.0.0 before end of the month.

I know we’ve been discussing a couple of bigger refactorings, especially for the setup/environment/container part but IIRC those would not change public APIs. Let me know if that’s not correct though.

There’s also an issue about introducing policy over configuration for resolving default configurations using a more explicit and flexible approach, unfortunately nobody had the time to do it and personally I wouldn’t want that to block 1.0.0. It can be postponed until 2.0.0 or maybe 1.x.y.

I also really wanted to make memory adapter more powerful and reusable for other adapters that could benefit from common in-memory operations; again, this shouldn’t block 1.0.0, we can do it later.

Finally, this is rom core gem I’m talking about, adapters and integration gems will remain below 1.0.0 as they are not mature enough (although rom-sql is getting there as it’s the most popular one).

With 1.0.0 beta out I’d like to focus on docs and guides and expose rom-repository more and explain properly how to use it. I know some people are still confused about it, not seeing why it’s so useful, which I’m planning to explain through docs and hopefully we’ll be on the same page soon :slight_smile:

My motivation behind pushing 1.0.0 sooner is to get more adoption and hopefully more contributions, unfortunately I won’t be able to work on ROM as intensively as I did in the last 12 months.

So, time for some big questions. Do you think it’s still too early? Does it feel not mature enough? Are we missing some crucial features? My answer is triple “no”, but it’s just me and my usecases are limited; however, ROM has been working amazingly well for me and from my point of view it feels like only polishing is needed and definitely better documentation, but as far as features go ROM is probably the most powerful persistence/mapping lib in the ruby world already and we’re just getting started.

Cheers!

2

I’ve found that most of what I’m missing from ROM can be added via the plugin interface (or by writing more adapters :slight_smile: ).

I also feel like the docs push should include some kind of demo application that walks people through the setup and usage of ROM.

3

Regarding setup/environment/container… for my proposal at least a few public APIs are touched on, insofar as Environment no longer takes the register_ or DSL commands. The “global use” API could conceivably remain unaltered, but ideally that’d be brought in line with the non-global API. For such a basic part of ROM it’d obviously be preferable to get any modifications in for a 1.0 release. I’ve taken a first stab at making sure the class structure I envision works, at least superficially, and am up for building out a serious PR based on my current proposal, or a modified one if anyone has any particular objections.

Proposal: https://gist.github.com/endash/3b436aa0d90fedc41c8b

4

Would be great if we could get that done before 1.0.0. Those changes won’t be too harmful as integration code for frameworks will be adjusted so apps will continue to work. For people who are using non-global setup it will probably be very easy to upgrade and since it’s not a change that will affect multiple places in apps, I think users will forgive us any potential API changes.

5

I’ll start putting together a real PR. Well, first I’m going to diagram out the class structure changes in order to communicate more explicitly what I’m planning. I should be able to get a first cut this week.

6

This is a rough sketch, not intended as documentation, but it shows the rough lay of the land.

7

Thanks! This looks like a nice separation. It would be nice if we could remove the global ROM.env container and make this optional. I’m actually thinking about add container support for rom-rails so that the railtie would simply configure rom, load components, and store the finalized rom container in the rails app’s container, so that we no longer have ROM.env.