Re: [Rails-devel] Versioning

[brett l. <bre...@gm...>]

Chris -

I agree. An auto-update feature would be nice to have.

It should go on the to-do list.

---Brett.


On Mon, Mar 29, 2010 at 9:37 AM, Chris Shaffer <chr...@gm...> wrote:
> 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
>
> ------------------------------------------------------------------------------
> 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
>