Feature #13194
closed
I'm lost
0%
Description
Dear Redmine developers, please hear me out...
I'm a long-time user and supporter of Redmine. Over the years, I've tracked lots of releases (started at 1.02, IIRC). Am now at 2.2.2. The system I maintain is being used by over a hundred participants and contributors. It's solid, it requires little effort to keep it running.
But there is a huge stumbling block for people like me, who are not very familiar with Ruby (I can help you with a dozen other languages, but Ruby is not one of them). Every time I want to upgrade, I fall flat on my face. Gems, bundler, rake - it's all Chinese to me (and that too is a language I do not speak - unlike the four which do I speak fluently).
I think there is room for improvement, and I think it is very much needed.
My current puzzle is how to get past this message and back on track:
rake db:migrate RAILS_ENV=production
/var/lib/gems/1.8/gems/bundler-1.1.4/lib/bundler/dsl.rb:75:in `gem':
You cannot specify the same gem twice with different version requirements.
You specified: shoulda (> 3.3.2) and shoulda (> 2.11)".Although I'd very much appreciate help on this, this issue is really a plea from me to you to create (or more clearly point to) a page which tells people like me how to keep Redmine updated over time. If a requirement of Redmine is "become a Ruby developer", then that should be clearly stated on the main requirements page. And if that is not a requirement, then please, please, please help non-Rubyists stay on the ball with all the wonderful developments and updates you're coming up with all the time.
As it stands, I fear every new update of Redmine, and have been doing so for several years now. Which is a friggin' shame, really.
The high water mark has probably been set by WordPress, which takes people through even major upgrades with no more than a button click in the web browser. But we don't have to aim that high to get most of the same benefits. I've been getting a lot of mileage out of doing svn update (or git pull, in my case, actually) and then these four steps after that:
rake db:migrate RAILS_ENV=production
rake tmp:cache:clear
rake tmp:sessions:clear
/etc/init.d/apache2 restartWorks quite well. Until gem dependencies break, that is - as they just did for me (for the Nth time). If you can streamline just that part, I think you'd get a lot of silent nods and second smiles...
Files
Updated by Jean-Philippe Lang almost 12 years ago
You specified: shoulda (> 3.3.2) and shoulda (> 2.11)".
Redmine depends on shoulda 3.3.2 but it looks like you have an extra dependency on this gem. Do you have any plugin with a Gemfile (eg. /plugins/*/Gemfile)?
Updated by Jean-Claude Wippler almost 12 years ago
- File redmine-upgrade-log.txt redmine-upgrade-log.txt added
Merci, Jean-Philippe, you've nailed it. I upgraded that plugin (a custom one developed for our forum by a friend), and now everything is progressing.
For reference, the history of every step I ended up taking, and a full log of the stuff flying by on the terminal screen. It's not so important, but illustrates how people like me stumble around in the dark at times. Keep in mind that almost nothing of that output makes sense to me (even though I'm totally familiar with Debian). As you can see in here, some issues take several steps to resolve - again, without having a clue what "nokogiri" is, for example:
svn update
git pull
rake db:migrate RAILS_ENV=production
bundle update
gem list
ls -a ~
vi /root/.gem/specs/rubygems.org%80/latest_specs.4.8
git branch
ls
ls -ltr
vi README.rdoc
git log
ls -l
rake db:migrate RAILS_ENV=production
ls plugins/*/gem*
ls plugins/*/Gem*
vi plugins/jl_question/Gemfile
rake db:migrate RAILS_ENV=production
bundle install
bundle update
gem install nokogiri -v '1.5.6
gem install nokogiri -v '1.5.6'
apt-get install libxslt-ruby
gem install nokogiri -v '1.5.6'
apt-get install libxslt1-dev
gem install nokogiri -v '1.5.6'
bundle update
rake db:migrate RAILS_ENV=production
rake tmp:cache:clear
rake tmp:sessions:clear
/etc/init.d/apache2 restartFeel free to close this issue, although I do hope it does plant some seeds for future docs. And thank you for the spot-on help.
-jcw
Updated by Jan Niggemann (redmine.org team member) almost 12 years ago
I agree that all these gems, bundler, rake, ... can be confusing for people not familiar with rails, but what exactly can be improved in RedmineUpgrade?
I have the same gut feeling as you, that documentation can be improved. I just don't know how. We have a lot of docs in the wiki, some really good, lots rather outdated, but how can we manage to make them more useable?
Updated by Ian Epperson over 11 years ago
I have a love/hate relationship with plugins for this very same reason - they seem to be the biggest stumbling blocks to upgrading. Each plugin developer gets to dictate exactly one version of some library, which may conflict the version another plugin developer decided to use. I've had plugins that look interesting but I can't get to install due to these conflicts.
Perhaps Redmine developers can create a method to coordinate plugin dependancies? Make specific versions of dependancies the "Redmine official" used one? If that's feasible, perhaps have a test install environment where these official dependancies are required, and if a plugin can't be installed with those requirements, it's rejected somehow?
Updated by Derric Atzrott over 11 years ago
I second third and fourth this request.
Documentation of all sorts is in a terrible shape for Redmine. From the point of view of a Sysadmin the documentation is terrible, and even from the developer standpoint I find the documentation terrible.
It seems the answer to every problem involves looking up arcane ruby and rails magic. Having to ask questions on Stack Exchange shouldn't be something that I find myself contemplating every time I have to make some sort of change to my setup, the documentation should provide the answers I need.
Perhaps a shell script could be written that runs the commands needed for an upgrade and spits out somewhat more useful error messages for non-ruby types?
Updated by Jean-Baptiste Barth over 11 years ago
- Status changed from New to Closed
- Resolution set to Invalid
Ian Little: the idea was once proposed of having official plugins, but it just takes too much effort for a small team. The fundamentals of redmine plugins evolved a bit from 1.x to 2.x but that shouldn't break on every minor release. Which it does, in reality, for various reasons, some very surprising. The very problem of the whole redmine plugins ecosystem is that most of them are not tested at all. In most cases we wouldn't even know how to automatically test that they don't fall in a 500 error with the next upgrade, but that's hard to automate if the plugin author didn't write some basic tests. I'd have some ideas to improve that but for now I stick with my own plugins only cause it bit me in the past, same as you.
@Derric: wow, that's a criticism. The wiki is open to everyone with a redmine account basically, so if you have precise idea on what to do on some pages, go! If it's more of a general trend, feel free to open an issue with your analysis on the subject ; maybe we just need a "ruby concepts for non-rubyists" page, as Opscode did with their "ruby for non-rubyists" in the Chef wiki. Assign the issue directly to me, I'd be happy to think about it with you and spend some time to fix things that need to be fixed. I find the few "official" docs (the ones maintained by the team, like RedmineInstall, Rest_api, ..) quite correct. As a sysadmin I find them linear enough with the required details to check prerequisites. But any precise/constructive criticism is welcome! I strongly encourage you to open a new issue with your thoughts.
@Jean-Claude: as this issue is solved I close the issue, thanks for the feedback!