Will there ever be a 1.3.0 release?

[Quintus]

The title basically says all. Last commit on master is about a year old, the 1.3.0 milestone is due for over a year now. Does it even make sense to build a web application relying on DataMapper now? I’ve always preferred DataMapper to ActiveRecord, but given the stalled development this does not seem a good choice anymore.

Valete.

[dkubb]

Check the release-1.2 branch for the gems you're using. Most of them have recent commits, sometimes multiple.

We need to have a better job of merging those back into the master branches, they it needs some testing. If you're interested in helping with this we'd love the help.

[dkubb]

@badshark asked me about this ticket via email and how he could help, and I replied with this email. I thought it might be helpful for others to see who are wanting to help with DM development:

The first thing I would do is join the #datamapper and #rom-rb IRC channels on freenode. That's where most development discussion happens. I'm "dkubb" on IRC.

As far as next steps I've been keeping the release-1.2 branches up to date, but I haven't had time to merge them back into the master branch yet. That's probably the first thing I would need help with. We have a decent CI system setup, so it should be clear when the build breaks, and I would want to make sure it's always in a passing state if possible.

If you want to start with opening a PR on dm-core that backports the release-1.2 changes to master (and fixes the conflicts of course) we can start with that and get the main issues out of the way before moving onto the other gems. In general dm-core sets the standard that the other gems need to meet, so we'll work on getting things squared away properly there first and the other gems should mostly follow the same pattern.

In case you're wondering my priority level of the gems for this kind of change, I would roughly list them as:

• dm-core
• dm-constraints
• dm-migrations
• dm-timestamps
• dm-transactions
• dm-types
• dm-validations
• dm-do-adapter
• dm-postgres-adapter
• dm-mysql-adapter
• dm-sqlite-adapter
• dm-active_model
• dm-rails

The next thing I would like to do with DM is integrate devtools with dm-core and the other gems. We're using this on ROM to make sure the code quality stays or improves on future commits. While DM development has slowed, I would still want to make sure that all new code we add is of the same level of quality as what we're doing in ROM.

I think we can add this to the master branch and then cherry-pick it into the release-1.2 branch. In fact I kind of wish we had been doing this all along, rather than developing in release-1.2 and then having to backport it; but I think we've learned it's not the best approach for keeping things up to date.

[nmccready]

Is there a gem repo that has 1.2.2 with in it? Also why is there a 1.2.1 dm-rails within gems list --remote, but it is not tagged on github?

[snusnu]

@nmccready just as a heads up: #259

i guess any help will be very much appreciated

[jf]

if I could just ask (because it's not readily apparent?), is DM now going away, and ROM (rom-rb.org) the new project to follow? Or is ROM going to be a fork of DM, while the development of DM still carries on with 1.x?

[nmccready]

@snusnu thanks! and @jf good info!

[solnic]

@jf no, ROM is a separate project and it's not replacing anything. It's a new thing, that is all. I cannot speak for @dkubb or @snusnu but personally I'm no longer working on DM as my main focus now is ROM.

[luissalazar]

Can you guys clarify something for me? How is ROM better than DataMapper? I mean no disrespect, I wonder for real :) I have a hard time accepting not being able to use DataMapper with Rails 4, and quite honestly, I cannot figure out how ROM is better. Is there any news about DataMapper per se and its future?

Thanks a lot guys. Your work is simply amazing. Both with ROM and DM (even more with DM lol)

[nixtrace]

@luissalazar ROM takes a very different approach to object mapping, as @solnic said it's a new project, not replacing DataMapper. I love where ROM is going, but I keep using DataMapper on production apps for now, so I definitely understand your concerns 😄

Ideally I'd like to keep DataMapper fresh until ROM will have a stable API.

I'm trying to merge all the fixes and small features that have been added to the release branch on the master branch, and after that release a new DataMapper version.

We're almost there: #259

Can you help us? 😄

[solnic]

@luissalazar I no longer maintain projects where DM is used so I don't have motivation to work on it as I'm focusing on ROM these days. Just like @badshark wrote - ROM is a different project and its highly experimental, we are still discovering how some things could be done and it's gonna take a lot of time to make it production ready.

[luissalazar]

@badshark Yeap, that I had it clear (the new approach from ROM [more like a conceptual real DataMapper]), but DM is such a lovely piece of software, it hurts not to be able to use in fresh projects... sits & cries hehehe
I would love too :) Don't know exactly how or if useful in any way, but I could give it a try :)

@solnic I understand.

Thank you guys for answering my questions. As I have said before, DM is just a wonderful piece of technology. I passively come to its github page occasionally with melancholic feelings :P hehe

Best regards from Costa Rica.

[basex]

guys do you have any upgrade path to move out of datamapper to one of the other ORM gems (rom, sequel, activerecord)? I tried this gem https://github.com/engineyard/ardm but it was not very straightforward to me.

[solnic]

@basex I can't imagine any upgrade path from DM to ROM other than a partial rewrite of the models and everything that interacts with them. Persistence layer is handled in a completely different way in ROM. Once ROM is close to 1.0.0 I'm happy to provide help with upgrading though, just ping me.

[martinemde]

I just noticed ardm was mentioned here. We're still actively developing ardm because our main app is locked in to DataMapper (we've hacked up to rails4 but otherwise we're in the same boat as many others).

My hope is that we can almost completely shim datamapper on top of active record. We've had a lot of success so far. I urge you to contact me directly or file issues on engineyard/ardm (even if they're just "wtf?" issues) and I'll do my best to answer them and improve documentation.

[basex]

I noticed some commits on the last days. So maybe we will have a a 1.3.0 version after all :)
https://github.com/datamapper/dm-core/blob/master/lib/dm-core/version.rb

[solnic]

@basex yeah we're trying to get crucial gems to a releasable state. I already managed to merge release-1.2 branch to master in dm-core and got rid off unfinished virtus integration. The build is passing on MRI 1.9-2.2 and rbx/jruby. There's still quite some work to be done in dm-types to merge release-1.2 into master and make sure all specs are passing but I'll get to it soon. I don't have much time for DM but I should be able to get dm-core, dm-types and dm-migrations 1.3.0 to a releasable state. If people can help with the rest we could push 1.3.0 release.

Regarding migration path to ROM, things started to clarify. I'm working on a rom-dm adapter and slowly porting an app from rails/dm to rails/rom. The adapter simply allows you to use DM as a backend for ROM (which is a natural way of using ROM so it's not any kind of a nasty hack or anything).

[martinemde]

As far as fixing all the dm-* projects for release, I've already done that here for most of them: https://github.com/ar-dm/

I did take some liberties in making this all work. For example I chopped out a few ruby versions, but they could be added back in. For the most part the ardm-* are very honest attempts to get all of the pending work on datamapper merged and released. Engine Yard Cloud is currently running on these versions and they pass on all rubies through 2.1.5 (and the tests are the only reason dm-core isn't working on 2.2, the code itself works fine as do most of the dm- projects).

If you'd like my help porting these over as dm- releases, let me know. I also suggest anyone who wants to help to try changing the names of dm-* gems to ardm-* in your gemfile and rebundle. Check here for more documentation on the change: https://github.com/ar-dm/ardm-core

[solnic]

That's good to know. What I did, which was important, was reverting
half-baked virtus integration. Then we merged release-1.2 branches into
master in most important projects.

We should probably look at ar-dm changes and port them to main projects if
it makes sense.

I guess we could push 1.3.0 of main projects (core, migrations, types,
validations and maybe a couple more) once all specs are passing and a bunch
of people confirmed it all works in their apps :)
On Sat 4 Apr 2015 at 01:59 Martin Emde [email protected] wrote:

As far as fixing all the dm-* projects for release, I've already done
that here for most of them: https://github.cob/ar-dm/

I did take some liberties in making this all work. For example I chopped
out a few ruby versions, but they could be added back in. For the most part
the ardm-* are very honest attempts to get all of the pending work on
datamapper merged and released. Engine Yard Cloud is currently running on
these versions and they pass on all rubies through 2.1.5 (and the tests are
the only reason dm-core isn't working on 2.2, the code itself works fine as
do most of the dm- projects).

If you'd like my help porting these over as dm- releases, let me know. I
also suggest anyone who wants to help to try changing the names of dm-*
gems to ardm-* in your gemfile and rebundle. If all tests pass then try
again with the versions loosened to ~> 1.2 to grab newer versions that
I've released since.

—
Reply to this email directly or view it on GitHub
#257 (comment).

[robclancy]

It's great working with dependencies with bugs that get fixed but you can't reliably get them into the project...

[basex]

I can make the tests work in some of the dm gems.
Can someone approve the pull requests?

[solnic]

@basex that would be lovely

[martinemde]

I started pushing PRs with the changes needed to modernize the dm gems based on ardm-* for datamapper/dm-active_model#5 and datamapper/dm-aggregates#21 so far.

The process is fairly simple. Pull down datamapper version at master, grab my ardm- version for that gem, then start with dm master version and rebase ardm/master version on top and fix the conflicts (usually based around changes I made for ardm naming). Then make sure all the ardm references are removed as you go, push and PR. I'll do more when I have a few more minutes. It takes about 20-30 minutes per gem all together.

Another thing of note is that I was able to break the strict dependencies between version of datamapper that required lock-stop versioning. For example, dm-aggregates works fine against dm-core 1.2 or (my version) of dm-core 1.3. We don't have to have such strict versioning so these newer versions can be released as they come along, not all at the same time.

I'd also like to reiterate. Anyone doing the fixes of these dm gems should really look at the ardm forks. I spent a few weeks fixing these gems, so at the very least copy what I did. I know we're all busy so I want us all to spend as little extra time as possible getting this fixed and merged.

[tpitale]

I'm currently in the process of attempting to close PRs and issues in preparation for a dm-core 1.3.0. Any help from anyone on this thread would be much appreciated!