Re: [Rails-devel] Versioning

[Chris S. <chr...@gm...>]

I concur with Jim. It took scheduling a long distance phone call with  
a 3 hour time difference just to get Rails installed on one less-than- 
tech-savvy friend's home computer. He won't upgrade unless it is  
impossible to play and it will almost certainly require another round  
of me talking on the phone and saying "after you clicked that button,  
what does it say?". When CyberBoard forced an upgrade recently, I  
learned that his install of that program was 5 years out of date.

Meanwhile, I update every time there is a new release.

p.s. It would be nice to have an in game check for and install updates  
feature.

--
Chris Shaffer

Please consider the environment before printing this email.

On Mar 29, 2010, at 9:27 AM, Jim Black <ji...@ko...> wrote:

> Brett,
>
> My post was titled "Versioning".
>
> In my reading, your comments below speak primarily to code  
> stability, and relative priorities of gaming bugs vs new titles.
>
> My comments weren't critical of Rails' stability, in general- and,  
> regardless- I think the new regression suites are critical, and will  
> make a profound improvement here anyway.
>
> Rather- I'm saying (a) it's very common for pbem tables to upgrade  
> Rails during a game, and, (b) it's very common for pbem users to be  
> running different versions of Rails /at the same time, at the same  
> table/.
>
> It would be useful if the Rails discussions, priorities, etc, simply  
> recognized this plain fact.
>
> Do with it, what you will- but, please- don't suggest most pbem  
> rails games are played start-to-finish by all the players with one  
> rails version; it's simply untrue.  Further- in my view, this leads  
> to simply ungrounded conclusions about the Rails user experience.
>
> - jim
>
>
>
>>
>> Jim -
>>
>> I think you're missing the point.
>>
>> Each of us volunteers their time to the development of this project.
>> The hours we dedicate are finite and limited.
>>
>> So, it's simply a question of how we spend that time.
>>
>> We certainly could spend that time making slow, deliberate, careful
>> changes that don't break save file compatibility and doing the
>> time-intensive regression testing to ensure that's the case.
>>
>> But... why would we? How does it help us achieve our goal of being
>> able to support playing as many 18xx games electronically as we can?
>>
>> If we do things that way, it would take us literally years to
>> implement any new feature because we'd need to painstakingly test
>> every nook and cranny of the code to make sure those changes didn't
>> break anything.
>>
>> Now, I'm not saying we shouldn't ever test anything. Stefan has  
>> done a
>> great job improving our ability to test saved games.
>>
>> My point is, our time is limited and we must choose where to spend  
>> that time.
>>
>> The whole point of the e-mail you're quoting is that my  
>> recommendation
>> on how to spend our limited time is to spend it on developing new
>> features, implementing new games, and generally getting Rails into  
>> the
>> state we'd like it to be in. The price we pay for focusing more on  
>> new
>> development is that we will not be able to spend as much time on
>> minimizing breakage.
>>
>> It's frustrating to hit a bug and have it tank your game. I  
>> understand
>> this, perhaps more intimately than you're giving me credit. However,
>> we can't be all things to everyone. Trade-offs and sacrifices are
>> necessary if we want to get anything done.
>>
>> ---Brett.
> =
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel