Menu
▾
▴
rails-devel
|
From: Jim B. <ji...@ko...> - 2010-03-29 16:27:27
|
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. = |
|
From: Chris S. <chr...@gm...> - 2010-03-29 16:37:34
|
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 |
|
From: brett l. <bre...@gm...> - 2010-03-29 16:40:53
|
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 > |
|
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 |
|
From: Erik V. <eri...@xs...> - 2010-03-29 22:06:09
|
On version compatibility: That is indeed what we strive for, but Rails is not yet mature enough to guarantee that. Sometimes improving quality cannot be done without breaking it: 1. When there is a bug fix that breaks an existing sequence of player actions. For instance, when some bug had changed the playing order; or when a missing action needs be inserted; or when a bug fix invalidates an actually played action (such as buying a train or share, because after the fix the company or player doesnt have the money any more); we have seen recent cases of all of these incompatibility causes. My impression is, that we have passed the peak of such bug fixes. It is very recently that Rails has started picking up significant usage, and it is no wonder that in that period lots of bug reports and fixes have occurred. Users have been keen to report these, and we have tried to issue fixes as soon as we could manage (perhaps a bit too soon sometimes). Anyway, I think Rails has been considerably hardened in the past months, also thanks to Stefan's efforts to fix all my Undo-related oversights. So there is hope that we have reached a higher level of stability now. 2. Occasionally we might find reasons to change the sequence of player actions, insert extra actions or delete spurious ones. For instance, I'm sometimes tempted to remove a 'Done' when that is the only real action that can be taken, but I have so far managed to resist that temptation. In any case, I think that such changes should never be done without prior discussion in this group. 3. Maintaining backwards compatilibily can necessitate adding special provisions, so that over time the program code may get polluted with code for only that purpose. Occasionally a cleanup might be in order. We havent done that for some time, and it is not really bad now, but over time the need for such a cleanup might arise. IMO that should only be done at a major (first version digit) or minor (second version digit) release, and with proper and prior announcement. The bottom line is, that backwards compatibility is a worthy goal, but sometimes it is impossible to achieve, and sometimes it must be broken for the good cause. Erik. -----Original Message----- From: Stefan Frey [mailto:ste...@we...] Sent: Monday 29 March 2010 19:08 To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] Versioning 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 ---------------------------------------------------------------------------- -- 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 |
|
From: Phil D. <de...@gm...> - 2010-03-29 20:51:26
|
My general thoughts on this is that it's a LOT easier for users to keep with one single version of rails for the entirety of one game than it is for the devs to have to worry about every piece of regression testing. Personally I currently have 4 versions of rails locally, one for each of 4 different PBEM games I have going and I have no trouble with this setup. I make sure I store the log files of every game I play as well (You can get the my.properties to do this for you) which means if there ever is a critical bug that requires upgrading, you can easily replay the game to that point in a newer version (Even the most complex game of 1830, once thinking time is removed, takes about 15 minutes to replay end to end) Phil On 29 March 2010 18:07, Stefan Frey <ste...@we...> wrote: > 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 > > > > ------------------------------------------------------------------------------ > 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 > |
|
From: Chris S. <chr...@gm...> - 2010-03-30 00:12:21
|
While maintaining four copies of the base program might be realistic for developers or tech savvy users, it is by no means realistic for average end users. There was a time, not so long ago, when you could reasonably assume that most, or nearly all, Rails users were tech savvy. However, in recent months Rails has been evangelized to a much wider audience. This is a tribute to the level of development and also to the developers! However, it introduces new realities to considerations of technical support and expectations of user behavior that are not compatible with the previous situation. There is no way that [name withheld to protect the identity of a highly skilled 18xx player who happens to be tech-unsavvy] will run four versions of Rails, but I still want to play Rails with him. -- Chris Please consider the environment before printing this e-mail. On Mon, Mar 29, 2010 at 1:51 PM, Phil Davies <de...@gm...> wrote: > My general thoughts on this is that it's a LOT easier for users to > keep with one single version of rails for the entirety of one game > than it is for the devs to have to worry about every piece of > regression testing. Personally I currently have 4 versions of rails > locally, one for each of 4 different PBEM games I have going and I > have no trouble with this setup. > > I make sure I store the log files of every game I play as well (You > can get the my.properties to do this for you) which means if there > ever is a critical bug that requires upgrading, you can easily replay > the game to that point in a newer version (Even the most complex game > of 1830, once thinking time is removed, takes about 15 minutes to > replay end to end) > > Phil > > On 29 March 2010 18:07, Stefan Frey <ste...@we...> wrote: > > 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 > > > > > > > > > ------------------------------------------------------------------------------ > > 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 > |
|
From: brett l. <bre...@gm...> - 2010-03-30 00:47:30
|
Chris - I agree with you. I hope that those people, like yourself, who have been encouraging new users to try out our software are also helping shoulder some of that support burden. We'll absolutely try to help where we can. Just be aware that the first step is very likely going to be upgrading to the latest version. :-) ---Brett. On Mon, Mar 29, 2010 at 5:12 PM, Chris Shaffer <chr...@gm...> wrote: > While maintaining four copies of the base program might be realistic for > developers or tech savvy users, it is by no means realistic for average end > users. There was a time, not so long ago, when you could reasonably assume > that most, or nearly all, Rails users were tech savvy. However, in recent > months Rails has been evangelized to a much wider audience. This is a > tribute to the level of development and also to the developers! However, it > introduces new realities to considerations of technical support and > expectations of user behavior that are not compatible with the previous > situation. > > There is no way that [name withheld to protect the identity of a highly > skilled 18xx player who happens to be tech-unsavvy] will run four versions > of Rails, but I still want to play Rails with him. > > -- > Chris > > Please consider the environment before printing this e-mail. > > > On Mon, Mar 29, 2010 at 1:51 PM, Phil Davies <de...@gm...> wrote: >> >> My general thoughts on this is that it's a LOT easier for users to >> keep with one single version of rails for the entirety of one game >> than it is for the devs to have to worry about every piece of >> regression testing. Personally I currently have 4 versions of rails >> locally, one for each of 4 different PBEM games I have going and I >> have no trouble with this setup. >> >> I make sure I store the log files of every game I play as well (You >> can get the my.properties to do this for you) which means if there >> ever is a critical bug that requires upgrading, you can easily replay >> the game to that point in a newer version (Even the most complex game >> of 1830, once thinking time is removed, takes about 15 minutes to >> replay end to end) >> >> Phil >> >> On 29 March 2010 18:07, Stefan Frey <ste...@we...> wrote: >> > 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 >> > >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > 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 > > |
|
From: brett l. <bre...@gm...> - 2010-03-29 16:38:27
|
Jim - My comments were mainly about what we, as a small, volunteer-based dev team can support. We can't really support games that are played across versions. While most of the time it'll work, there are going to be versions that don't work together very well, or at all. If we try to provide support for games involving multiple versions, inevitably we'll end up spending significant amounts of time re-discovering old issues where the solution is to upgrade. I understand what you're saying, and to some extent, I agree with you. I can't dictate how people use our software and I'm not about to try. However, what I _can_ do is provide guidelines for best practices and what to expect when asking for help. ---Brett. On Mon, 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 > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X