Stephen, > The dependencies.rb file is very precise about which versions it > wants, and has a 'strict version' comment at the top to discourage > people screwing with it. But the versions are always out of step with > DM's latest versions.
The config/dependencies.rb file is generated to use whatever version of DataMapper was current at the time of the Merb release. Until DM's API is frozen at 1.0, using strict version dependencies is probably the only sane approach. Mixing and matching different versions of DataMapper will probably lead to madness, just because of how quickly we are evolving the API. One issue we have is that DM's versioning process is a bit different from what you'd expect in other open source projects. Perhaps that is my fault. The truth is that every revision change (the "10" component in the version 0.9.10") could result in a minor non-backwards compatible API change. That's why we always bind the dm-more gem version so tightly to the dm-core version. If we had been numbering things according to standard practice for open source projects, we'd probably be somewhere between 0.20.0 and 0.30.0. I suppose we could start doing that if people think it wouldn't cause even more confusion. The rationality I've been using to keep us in the 0.9.x series for so long has been that there's been no major API changes, and that we will change to a more traditional version numbering system after 1.0 is out. My thoughts are that DM is in beta right now, while we figure out the optimum abstractions to work with the largest number of storage systems. When I say beta, I don't mean in the google sense either :P, I mean that the API is still undergoing rapid improvements and evolution as our understanding improves. I expect once we hit 1.0 that any minor API changes will result in a minor bump to 1.1, and any major changes will bump the major version to 2.0. > Even this wouldn't be a problem -- Rubygems is supposed to be good at > letting you keep and use older versions -- except for the "already > activated" error that Glenn mentioned. Mine looks something like this > when I try to run autospec: > > ***** > /Library/Ruby/Site/1.8/rubygems.rb:149:in `activate': can't activate > dm-core (= 0.9.10, runtime), already activated dm-core-0.9.11 > (Gem::Exception) > ***** > > What I interpret from that is that something already required the > dm-core gem before the Merb init code loaded that dependencies file. > And when it required it, it simply loaded the latest version. What would be interesting is tracking down whatever required dm-core 0.9.11. Aside from your config/dependencies.rb, nothing inside merb should ever require dm-core. As mentioned elsewhere in this thread, if I update all the dm-more gem deps to be fixed using "=" then there won't be any chance of a dm-more gem requiring anything other than the exact version of dm-core it will work with. I'm pretty sure I will be making this change shortly, provided there are no objections. > For me this usually doesn't happen when I try to run 'merb', and only > on some rake tasks. It's mostly specs that break it. But since I > practice BDD and I'm running specs *all the time*, this causes me a > lot of stress. It means I know that if I do a 'sudo gem update', I'm > going to have to spend some time fixing all the dependencies.rb files > in all of my Merb projects before I can work with them again. And > that's no fun. Yeah, let's see what we can do to make this unnecessary. So far I have two action items to lessen this problem: 1) Backport the system from dm-core next that will only require a DO driver if it is explicitly being used. This will resolve the interdependencies between data_objects and the other DO drivers. 2) Update dm-more gems to reference dm-core using the exactly specified version. This will prevent situations where a dm-more gem is required prior to dm-core, pulls in the highest available dm-core on the system, when you really want to use a lower specific version. Anyone have more ideas? If not I can make these changes within the next couple of days and push a DM 0.9.11 gem release. Then we can re- examine things and see if the problem is resolved or not, and try another approach. -- Thanks, Dan (dkubb) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
