James, Is there anything we're missing now? I tried pretty hard to test older versions, and having a good CI suite would have helped. If there's something we're missing now I'd like to get it filled in.
On Mon, Oct 11, 2010 at 4:34 PM, James Tucker <jftuc...@gmail.com> wrote: > > On 11 Oct 2010, at 16:17, Chad Woolley wrote: > > > On Mon, Oct 11, 2010 at 4:55 AM, James Tucker <jftuc...@gmail.com> > wrote: > >> > >> Actually, with the way that integration works (another thing I'd like to > address), upgrading rubygems seems to have some errors. This also reaches > back into gemcutter, whereby I am concerned that we cannot continue to make > sweeping changes like just turning off indexes without breaking versions. If > this becomes the case for 1.9.2 before it's even in use as a mainstream > version, that would be very sad. This is also (personally) my concern with > opening up the project too fast, patches need to have some serious thought > put into them with regard to portability and longevity. As you note > yourself, this project services quite a wide scope, and that should be > addressed. > > > > The correct way to address these risks and concerns is to have > > adequate integration tests and continuous integration environments, > > which allow you to be confident that any given change, in any branch, > > will not [severely] break any environment which you care about. > > Features were removed from production servers. That was a conscious human > choice. What I'm saying is that if this happens again, the affect to 1.9.2 > will be even worse. At least old 1.8.x systems can relatively happily > upgrade rubygems to a working version (albeit probably outside their package > manager). My point is that kind of indiscretion won't be recoverable in > future unless these (process) issues are addressed. History proves that at > least a while ago, my views were not shared. We should try to keep a > reasonable support time on older versions. I know the ruby community moves > fast, but that doesn't really make it acceptable to break production > "stable" systems within a year of release, IMO. > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
