Re: [Rails-devel] Rails 1.x release and branch management (was: Problem with 1835 Tests)

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

Martin please excuse me: This answer was hold back in my draft folder 
for even longer.

This belongs to the discussion of Rails release management. Last week I 
proposed a Rails 2.x release strategy. This was my take on Rails 1.x:

Hi Martin,
sorry for my late reply, I did not look into that issue immediately.

The master branch is out-of-date with respect to the current development
of rails 1.x.

In the end the master branch served more like Erik's private development 
branch from which I picked the or merged the relevant code parts into 
the release branches. Main reason was that Erik preferred to keep the 
master branch name.
Erik: Please do not hit me that I worked around your preferences ;-)

So there is no need to merge or upgrade with the master branch.
And no issues with the tests there, as most likely as you found out
might also be due to white-space issues.

For the future I suggest the following:
=> You act as the maintainer of the Rails 1.x development and feel free 
to choose your own release strategy, which you feel comfortable with.

=> It would be great you could follow the naming convention from 
proposal from Rails 2.0: Thus feel free to choose any name for 
development, however official branches should start with "rails_1_"
e.g. "rails_1_release".

Stefan











On 10/04/2013 01:00 PM, Martin Brumm wrote:
> Hi Stefan, Erik,
>
> somewhere in between the 1.7.10 and the current HEAD of the 1.7.x branch
> the reprocessing of save games in 1835 falls for specific szenario.
>
> From what i was able to see:
> The stepobject inside the OR doesnt get advanced (OR5.2 Opcompany BY) if
> Opcomp lays a tile to the next OR Step (probably has to do with the rare
> case that the OPcomp here owns a private which would allow another
> tilelay for free.
>
> This leads to the point that the internal representation of StepObject
> differs from the recorded Action.
> I.e. the recorded action is NullAction.SkIP (for skpipping the LayToken)
> but the Step.Object is still pointing at LAY_TRACK.
> The subsequent action SetDividend then fails because the Internal
> StepObject is pointing at LAY_TOKEN.
>
> Somehow the Nullaction regarding the special TileLay isnt recorded there
> valid.
>
> If one plays the interrupted game to the end and saves that builds a new
> report, that then tests ok.
>
> But the master branch doesnt fail but subsequently fails on the new
> savegame and report.
>
> So that puts us in the position that master is not reflecting the state
> of rails1.7.x.
>
> And my question now would be how to proceed to release 1.8 ?
>
> We are ready with 1880,  rails1.7.x_1880 is a branch based on the latest
> rails1.7.x which incorporates all from specific_1880. and could be used
> to release 1.8.
>
> but how should i incoporate specific_1880 into the master branch ?.
>
> Kind regards,
>
> Martin
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>