From: brett l. <bre...@gm...> - 2011-08-11 17:25:54
|
On Thu, Aug 11, 2011 at 10:09 AM, Stefan Frey <ste...@we...> wrote: > On Wednesday, August 10, 2011 12:31:42 pm Erik Vos wrote: > However as I seem it hardly possible to refactor against a moving target (as > you are stilling adding new functions to the core classes - and rightly do so, > as long as there is no alternative), I suggest to create a new branch inside > the git repo for a potential Rails 2.0. > > This branch would allow to refactor main parts without any fear to break the > existing code/games/save files etc. It would also allow cleaning up from > legacy code and components and a better support for unit testing. > > In the main trunk new games/features could still be added to Rails 1.x, until > Rails 2.0 is stable/mature enough. > > Stefan I'm open to this. It sounds like public topic branches may be necessary for publishing larger chunks of work prior to being merged into master. It may also help us discuss more extensive changes, if we can pull down a published branch to review the changes. Sharing the code is often easier than trying to describe the idea. Pushing a new branch is easy: 'git push origin remotebranch', which is shorthand for 'git push origin localbranch:remotebranch' Deleting branches is also easy: 'git push origin :remotebranch', which means "push NULL to remotebranch" I also agree with the assertion that some of our classes have probably become "catch-all" buckets for functionality. I've been having similar problems un-knotting the XML parsing code from the *Manager initialization code. It's a bit of a mess. ---Brett. |