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
