Menu
▾
▴
Re: [Rails-devel] Versioning
|
From: Stefan F. <ste...@we...> - 2010-03-29 17:07:51
|
My comments on the issues discussed: Auto-Update: I do not think that is possible and/or wise to do from inside Rails. Colossus (the titan game) supports the Java Webstart option. It still requires the installation of Webstart first and this could fail on some systems as well. However new releases of Webstart are less frequent compared to Rails. Versions and pbem: From my knowledge of the code Erik always emphasizes the backward (code) compatibility of the Rails save files. As the game files are simply the stack of player's actions most issues arise if a bug fix that either restricts the strategy space (by preventing previously possible but illegal moves) or requires an additional activity of a player. Thus I would recommend upgrading to newer versions of Rails even for in-progress pbem as from that point on you benefit from the bug-fixes of the more recent versions. And I hope that the number of bugs fixed exceeds those created with each release. Regression tests: see my next e-mail, which went out to the users list last week, but did not make it to the devel list: save files of Rails (pbem) games are helpful to indicate upcoming version conflicts. Stefan On Monday 29 March 2010 18:40:27 brett lentz wrote: > 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® 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® 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® 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 |
