[katello-devel] moving to ruby 1.9.3

[David Davis]

I think using Gemfile.lock is a great idea. It would give us some oversight into gem versions and gem versions changing by way of reviewing pull requests to Katello. Currently, I just upload rails 3.2.8 to our gem repo and break all new development installs of Katello (as rails 3.2.8 matches our Gemfile requirement of '>= 3.0.10' yet it does not work with our project in its current state). There's no review process to our katello-thirdparty git repo and until there is, I think locking down gem versions in the Gemfile.lock is a much better idea.

David

----- Original Message -----
> From: "Lukas Zapletal" <lzap at redhat.com>
> To: katello-devel at redhat.com
> Sent: Friday, October 19, 2012 4:21:23 AM
> Subject: Re: [katello-devel] moving to ruby 1.9.3
> 
> On Wed, Oct 17, 2012 at 08:46:27AM -0700, Michael McCune wrote:
> > On 10/17/2012 08:37 AM, Dmitri Dolguikh wrote:
> > >As part of port to Ruby 1.9.3, I'd suggest moving away from custom
> > >ruby
> > >repository for bundler-based installs, and switch to rubygems.org
> > >repository instead. Folks still would rather use Fedora-provided
> > >gems
> > >can do so, since Fedora 17 versions of 'bundler' and 'gem' are
> > >yum-aware. This would simplify dependency management during
> > >development.
> > 
> > this sounds appealing, what is the best way to 'try it out' from a
> > fresh install perspective?
> 
> I like the idea of getting rid of our gem repo, but lemme ask this.
> Is
> there any way of controlling how folks are updating versions in lock
> files?
> 
> I mean, we built our gem repo because of "instability" of
> Gemfile.lock
> file. Very often someone commited a version bump of something
> incompatible - bang.
> 
> I expect this should be much better now since we use review request
> and
> we will discuss every single Gemfile change. But in any case, we
> should
> take care!
> 
> > >As the next step I'd like to propose to switch to rails 3.2 (the
> > >version
> > >of Rails that's going to be shipped with f18) in master (which is
> > >what
> > >Aeolus folks did).
> > >
> 
> Why not, but I vote for only upgrading Rails and keeping other
> libraries
> on oldest versions possible. I mean, not doing "bundle update" for
> all,
> but just for Rails and doing this carefully step by step, library
> after
> library. Of course, while keeping versions in our spec files in sync.
> 
> ps - But what I do not agree is splitting up into development phase
> and
> packaging phase :-) I sent another reply in the thread. Every single
> dev can do the split on his own - making "longer" development cycle
> in
> his own branch and preparing packages just before the git pull
> request.
> 
> LZ
> 
> --
> Later,
> 
>  Lukas "lzap" Zapletal
>  #katello #systemengine
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
>