Re: [Rails-devel] 1880 Implementation: Opinions wanted

[Stefan F. <ste...@we...>]

Martin, Erik & Frederick:
this is a summary answer to the discussion that arose after this mail:

 From the beginning I clearly stated that it is my intention to make 
some changes to the internal working of Rails, especially to the state 
and model packages and then moving up to the round classes.

Master and Rails2.0 started to deviate after release 1.5 and I have
no intention to merge all commits after that now:

The main obstacle to merge things now is that there is no way to decide 
if they are functionally correct, as the Rails 2.0 does not even compile 
now. So I would not recommend anyone to merge at this point in time.

If the 1.x merges get merged and by whom later on is open: Simple bug 
fixes most likely can be merged easily, your stuff should be mergeable 
after a few changes, however other things will be more difficult, but 
not impossible.

Most likely Martin's argument is correct: Why waste the time to wait for 
Rails2.0 to start developing, if one has spare time to do so now.
In the worst case one can use the experience from that to add an even 
better implementation to Rails2.0 at the time the development of 2.0 
allows to do so.

So my main point is to keep the issue transparent to avoid 
disappointment later but I do not actively discouraging all of you who 
are keen to add new features which work immediately.
However I currently prefer to improve the base layer where everything 
can be built upon.

Stefan



On 01/29/2012 05:12 PM, Frederick Weld wrote:
> @Martin&  Erik:
> When reading this thread, I'm wondering how you will merge all these
> changes to the game engine into 2.0.
> Perhaps I'm missing some important information here, but as far as I
> know, all changes to game engine will be dropped when migrating to
> 2.0.
>
> @Stefan:
> Wouldn't it make sense if master was merged right now into 2.0 and,
> from that point in time on, everyone who changes master is responsible
> for also keeping 2.0 up-to-date? (still keeping two separate branches,
> of course, for retaining a working version )
> That would have the benefit that everyone can directly perceive
> whether his changes will be valid in 2.0 (and, if not, how to adjust).
> If only merging once 2.0 is ready, we will have to deal with
> incompatible commits that were performed several months ago the
> content/interdependencies of which have long been forgotten...
> At least for me, I would prefer double-maintenance now to that
> situation in the near future.
>
> --Frederick
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel