rails-devel — List for discussion of Rails development

[Rails-devel] Branching (was: Rails 1.5.1 available)

[Erik V. <eri...@xs...>]

Small changes and fixes I'm currently doing directly in the master branch.
For more substantial work I create local branches, that I merge into master
before pushing to the repo.

I have one problem with branching, though: you can't switch branches easily
if you have uncommitted work.  And I don't like creating commits for small
bits and pieces.

I know you can use 'git stash' to put away uncommitted work (index
included), but git stash does not seem to honour .gitignore.  Or perhaps its
Egit's handling of 'git add'.  
Yesterday I tried stashing for the first time, and 'git stash pop' failed on
18xx.log files that are included in my ignore files. (I think these logs are
created by JUnit test runs. Perhaps I have just badly configured my log
location).

At least one would expect that the index would be saved when switching
branches, but that does not seem to be the case. And stashing is a hassle.
This is my only major gripe with Git so far.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> > IMO, it's easier to leave master as the lineage of stable changes and
> > do any new development in (usually local) branches that can be merged
> > into the stable trunk when they're ready.
> >
> > In git, branches and tags are both very very cheap (and fast), unlike
> > SVN. So, if you want to have all development happen in master, then
> > branch off for stable releases, we can do that too.
> 
> Substantial changes have still should be done inside separate branches,
like
> my start of refactoring some parts in the Rails 2.0 branch.
> Stefan

[Rails-devel] Release strategy (was: Rails 1.5.1 available)

[Erik V. <eri...@xs...>]

With Brett, I would prefer to see release tags in the master branch, so we
can see what's in a release. But I have no serious problems with Stefan's
approach if he is convinced that it's better.

For completeness sake, just one more remark: IMO 3rd-digit releases should
not be reserved for bug fixes only. Small improvements, and perhaps even not
so small ones, should be included as well.  I have a feeling that our users
are much better testers than that we are, so withholding updates until we
think these are really stable might backfire.  I'd rather have a bug
reported sooner than later.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, October 10, 2011 8:14 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Rails 1.5.1 available
> 
> >
> > It's far more important to me that each release is accessible from the
> > repo. How it achieves that is totally negotiable.
> >
> > Personally, because you and Erik are far more active in the project
> > than I am, I'm willing to give your preferences a bit more weight than
> > mine. ;-)
> >
> > IMO, it's easier to leave master as the lineage of stable changes and
> > do any new development in (usually local) branches that can be merged
> > into the stable trunk when they're ready.
> >
> > In git, branches and tags are both very very cheap (and fast), unlike
> > SVN. So, if you want to have all development happen in master, then
> > branch off for stable releases, we can do that too.
> 
> I understood that for Erik the latter is the preferred choice. And I do
not mind
> to manually pick the fixes into a separate branch at the time of release.
> So everyone can contribute simply to the master and does not have to care
if
> where to push depending if it is a bug-fix or a new development. The only
> thing to ensure is that the master branch compiles and runs after each
> commit.
> 
> Substantial changes have still should be done inside separate branches,
like
> my start of refactoring some parts in the Rails 2.0 branch.
> Stefan
> 
> 
> 
> 
> 
>
----------------------------------------------------------------------------
--
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Keeping compatibility (was: Test report: 1835 in Rails 1.5.1)

[Erik V. <eri...@xs...>]

I agree that tidying up these behaviours would be a good thing. 

I think removing popups is easy to do.  Pressing the 'OK' on such popups does not count as a player action. 

But removing unnecessary 'Pass' and 'Done' actions is a different matter, because it has a bad side effect: all saved games that contain at least one such removed action will no longer load. At least not without special compatibility code to detect and catch such cases (and I'm not sure if it's feasible at all).  This is especially bad for the developers, who heavily rely on sometimes pretty old saved files for testing.

This consideration has so far kept me from removing such actions.  The one case I once did has caused me a lot of trouble.

Ultimately we will have to bite the bullet.  There is already quite some compatibility code that I would like to get rid of as well.
Would it be an idea to set this as a goal for Rails 2.0?  Or 2.1?  Remember: it means that we will have to rebuild all test cases.  Not just those in the repository.

Erik.

> -----Original Message-----
> From: brett lentz [mailto:bre...@gm...]
> Sent: Tuesday, October 11, 2011 3:19 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Test report: 1835 in Rails 1.5.1 (Windows XP)
> 
> On Mon, Oct 10, 2011 at 8:13 PM, John David Galt
> <jd...@di...> wrote:
> > Observations in playtest game of 1835 on Rails 1.5.1 on 2011-10-10.
> >
> > 2. During a starting packet purchase round, if a player cannot take
> > any action (has too little money to buy anything currently available)
> > a popup appears "[name] cannot buy anything" with an OK button.  If
> > two players are skipped they are combined on one popup.  That's cute,
> > but I'd prefer the turns be silently skipped.
> >
> > Oddly enough, the stock round behavior is not the same.  If a player
> > cannot take any action on his stock turn (he has too little money to
> > buy anything currently available, and owns nothing that can currently
> > be sold) he still gets a turn, even though "Pass" and "Autopass" are
> > the only actions allowed.  Again, I'd prefer the turn be silently skipped.
> >
> 
> My suggestion is that these behaviors should:
> 
> 1. Be consistent.
> 2. Have a preference for whether the user wants to explicitly hit "next" (or
> an equivalent) or automatically skip no-op actions.
> 
> ---Brett.
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity and more. Splunk takes this data and makes sense of it.
> Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Test report: 1835 in Rails 1.5.1 (Windows XP)

[brett l. <bre...@gm...>]

On Mon, Oct 10, 2011 at 8:13 PM, John David Galt
<jd...@di...> wrote:
> Observations in playtest game of 1835 on Rails 1.5.1 on 2011-10-10.
>
> 1. I appreciate the changing of major company abbrevs to two letters, but
> the "Bay" president's share in starting packet seems to have been left out.
>
> 2. During a starting packet purchase round, if a player cannot take any
> action (has too little money to buy anything currently available) a popup
> appears "[name] cannot buy anything" with an OK button.  If two players are
> skipped they are combined on one popup.  That's cute, but I'd prefer the
> turns be silently skipped.
>
> Oddly enough, the stock round behavior is not the same.  If a player cannot
> take any action on his stock turn (he has too little money to buy anything
> currently available, and owns nothing that can currently be sold) he still
> gets a turn, even though "Pass" and "Autopass" are the only actions
> allowed.  Again, I'd prefer the turn be silently skipped.
>

My suggestion is that these behaviors should:

1. Be consistent.
2. Have a preference for whether the user wants to explicitly hit
"next" (or an equivalent) or automatically skip no-op actions.

---Brett.

[Rails-devel] Test report: 1835 in Rails 1.5.1 (Windows XP) - corrected

[John D. G. <jd...@di...>]

Observations in playtest game of 1835 on Rails 1.5.1 on 2011-10-10.

1. I appreciate the changing of major company abbrevs to two letters, but
the "Bay" president's share in starting packet seems to have been left out.

2. During a starting packet purchase round, if a player cannot take any
action (has too little money to buy anything currently available) a popup
appears "[name] cannot buy anything" with an OK button.  If two players are
skipped they are combined on one popup.  That's cute, but I'd prefer the
turns be silently skipped.

Oddly enough, the stock round behavior is not the same.  If a player cannot
take any action on his stock turn (he has too little money to buy anything
currently available, and owns nothing that can currently be sold) he still
gets a turn, even though "Pass" and "Autopass" are the only actions
allowed.  Again, I'd prefer the turn be silently skipped.

3. If the start packet does not sell out in first round, the unsold shares
are not accounted for in the "Game Status" window.  They do not appear in
the IPO column, bank pool, or anywhere else.  (I suggest adding a column
for "Reserved" shares -- which would also include the 60% of PR that will
be exchanged for privates and minors.)

4. The bug reported in Game Notes, where the game would hang if the By did
not float in the first round, is no longer fatal, at least for me.

To be exact: As soon as the "Start Round" is passed out, focus moves to the
Game Status window, and its "Pass" and "Autopass" buttons change color as
if they'd been enabled (but that window's name does NOT change to "Stock
Round [n]", and a popup "Error: No action available" appears).

I worked around this by simply doing File -> Save on the menu bar and
saving the game.  (A restore wasn't needed.)  This moved the focus to the
map window and made it an operating round, which of course is how it should
have been.  When the OR finished, "Start Round" reappeared on the screen.

5. Nit: The first operating round is still "0.1".

6. The columns "Current" through "Tokens" on the Game Status window are too
wide, apparently because they've been constrained to match the line showing
the number of trains of each future type.  I would prefer that the list of
future trains be allowed to word-wrap, especially because it already takes
up two lines if any player owns two private companies.

7. I really appreciate your enabling scroll bars on the Game Status window
so that the window no longer frequently and automatically changes size.

I propose a similar change to the Map window, which seems to frequently set
itself to extend way beyond the screen (thus making me manually resize and
move it) several times per game, either because the number of companies has
changed or because a company laid a tile or token that required one of
those columns in the list of companies to resize itself.

(Conversely, the Tokens column does not resize itself when it gets so
narrow I can't see the number of tokens a company has left, and I wish it
did!)

8. Unlike most companies, a PR token does not appear on the Stock Chart
until the M2 is traded in to form the PR.  I propose that the PR token,
appear as soon as any player buys a share of PR, even though the shares
can't be sold until the M2 is traded in.  (Other companies' shares can't be
sold until they have operated, but their tokens appear on the Stock Chart
as soon as someone buys the president's share.)

9. The Pfalzbahnen owner is being offered opportunities to lay a token
using its special power even when impossible (because the company currently
operating has run out of tokens and/or already has one in the Pfalz hex).

10. The Map window now allows a "Special" action to close private companies
voluntarily.  I don't think this is legal in 1835.  (I ran across this while
looking for a command to use Pfalz's power to lay a tile.  I think this
"Special" menu would be a much better place for tile- and token-laying
powers to be, rather than make the user click "No Tile" or "No Token" an
extra time every turn.  But I suppose that's a style issue.)

11. The tile-laying logic is mostly correct but still suggests tile lays
where the new tile is rotated in a way that makes it not connect to any
station of the company.  And there are situations where some tile lays are
allowed but nothing gets suggested.

(This game, the Pfalz owner did not have a major company before Phase 3, so
I was unable to verify whether it still offers the Pfalz tile-lay on every
major-company turn of that player during yellow phase, which should never
happen because the tile lay is impossible then.)

12. The token-laying logic similarly still makes mistakes.  It suggests
every turn that BY lay a station marker in the south side of Nurnberg-
Furth, even though it laid one on the north side in OR2 using the NF.

(Oddly enough, in a problem that resembles point 3 in reverse, the five PR
tokens that are supposed to be reserved for exchanging minor company tokens
*do* show up as available to be built.  Next time I'll try to build them in
arbitrary locations and see what happens -- both then and when the minor
companies merge and there aren't any PR tokens for them.)

13. The revenue calculator consistently shows the correct runs for M6 on
the map but calculates their value as 20M too low (40 from green Hamburg
to yellow Kiel, which should be 60).  Mousing over the map reveals the
underlying problem: northwest Hamburg is value 20, not 40, in the tile list
(or wherever this information is stored for preprinted cities).

14. The game reaches the point of the attached save file.  When the PR
buys the 5-train, SX has to discard a train (correctly changed from
happening upon purchase of the 4+4).  But then the game hangs while trying
to merge the remaining private and minor companies.  I had to "undo" the
5-train purchase (using the report window) to be able to save the game.

I've included the log as well.

[Rails-devel] Test report: 1835 in Rails 1.5.1 (Windows XP)

[John D. G. <jd...@di...>]

Observations in playtest game of 1835 on Rails 1.5.1 on 2011-10-10.

1. I appreciate the changing of major company abbrevs to two letters, but
the "Bay" president's share in starting packet seems to have been left out.

2. During a starting packet purchase round, if a player cannot take any
action (has too little money to buy anything currently available) a popup
appears "[name] cannot buy anything" with an OK button.  If two players are
skipped they are combined on one popup.  That's cute, but I'd prefer the
turns be silently skipped.

Oddly enough, the stock round behavior is not the same.  If a player cannot
take any action on his stock turn (he has too little money to buy anything
currently available, and owns nothing that can currently be sold) he still
gets a turn, even though "Pass" and "Autopass" are the only actions
allowed.  Again, I'd prefer the turn be silently skipped.

3. If the start packet does not sell out in first round, the unsold shares
are not accounted for in the "Game Status" window.  They do not appear in
the IPO column, bank pool, or anywhere else.  (I suggest adding a column
for "Reserved" shares -- which would also include the 60% of PR that will
be exchanged for privates and minors.)

4. The bug reported in Game Notes, where the game would hang if the By did
not float in the first round, is no longer fatal, at least for me.

To be exact: As soon as the "Start Round" is passed out, focus moves to the
Game Status window, and its "Pass" and "Autopass" buttons change color as
if they'd been enabled (but that window's name does NOT change to "Stock
Round [n]", and a popup "Error: No action available" appears).

I worked around this by simply doing File -> Save on the menu bar and
saving the game.  (A restore wasn't needed.)  This moved the focus to the
map window and made it an operating round, which of course is how it should
have been.  When the OR finished, "Start Round" reappeared on the screen.

5. Nit: The first operating round is still "0.1".

6. The columns "Current" through "Tokens" on the Game Status window are too
wide, apparently because they've been constrained to match the line showing
the number of trains of each future type.  I would prefer that the list of
future trains be allowed to word-wrap, especially because it already takes
up two lines if any player owns two private companies.

7. I really appreciate your enabling scroll bars on the Game Status window
so that the window no longer frequently and automatically changes size.

I propose a similar change to the Map window, which seems to frequently set
itself to extend way beyond the screen (thus making me manually resize and
move it) several times per game, either because the number of companies has
changed or because a company laid a tile or token that required one of
those columns in the list of companies to resize itself.

(Conversely, the Tokens column does not resize itself when it gets so
narrow I can't see the number of tokens a company has left, and I wish it
did!)

8. Unlike most companies, a PR token does not appear on the Stock Chart
until the M2 is traded in to form the PR.  I propose that the PR token,
appear as soon as any player buys a share of PR, even though the shares
can't be sold until the M2 is traded in.  (Other companies' shares can't be
sold until they have operated, but their tokens appear on the Stock Chart
as soon as someone buys the president's share.)

9. The Pfalzbahnen owner is being offered opportunities to lay a token
using its special power even when impossible (because the company currently
operating has run out of tokens and/or already has one in the Pfalz hex).

10. The Map window now allows a "Special" action to close private companies
voluntarily.  I don't think this is legal in 1835.  (I ran across this while
looking for a command to use Pfalz's power to lay a tile.  I think this
"Special" menu would be a much better place for tile- and token-laying
powers to be, rather than make the user click "No Tile" or "No Token" an
extra time every turn.  But I suppose that's a style issue.)

11. The tile-laying logic is mostly correct but still suggests tile lays
where the new tile is rotated in a way that makes it not connect to any
station of the company.  And there are situations where some tile lays are
allowed but nothing gets suggested.

(This game, the Pfalz owner did not have a major company before Phase 3, so
I was unable to verify whether it still offers the Pfalz tile-lay every
turn during yellow phase, which should never happen.)

12. The token-laying logic similarly still makes mistakes.  It suggests
every turn that BY lay a station marker in the south side of Nurnberg-
Furth, even though it laid one on the north side in OR2 using the NF.

(Oddly enough, in a problem that resembles point 3 in reverse, the five PR
tokens that are supposed to be reserved for exchanging minor company tokens
*do* show up as available to be built.  Next time I'll try to build them in
arbitrary locations and see what happens -- both then and when the minor
companies merge and there aren't any PR tokens for them.)

13. The revenue calculator consistently shows the correct runs for M6 on
the map but calculates their value as 20M too low (40 from green Hamburg
to yellow Kiel, which should be 60).  Mousing over the map reveals the
underlying problem: northwest Kiel is value 20, not 40, in the tile list
(or wherever this information is stored for preprinted cities).

14. The game reaches the point of the attached save file.  When the PR
buys the 5-train, SX has to discard a train (correctly changed from
happening upon purchase of the 4+4).  But then the game hangs while trying
to merge the remaining private and minor companies.  I had to "undo" the
5-train purchase (using the report window) to be able to save the game.

I've included the log as well.

Re: [Rails-devel] Rails 1.5.1 available

[brett l. <bre...@gm...>]

I suspect it was my own lack of knowledge on the whole process.

Our classloader (and hex drawing code) comes from the Colossus project
( http://colossus.sourceforge.net/ ), and they provide a JNLP.  So, I
doubt there's any technical blockers to providing one.

---Brett.



On Mon, Oct 10, 2011 at 2:15 PM, Stefan Frey <ste...@we...> wrote:
> Do you remember what the main obstacle was? I suspect the
> custom made classloader?
>
> On Monday, October 10, 2011 08:05:20 pm brett lentz wrote:
>> I looked at creating a JNLP several years ago, but couldn't really
>> make heads or tails of the process.
>>
>> If you can make it happen, that'd be awesome. I'd love to have a link
>> on the website that people can click on to launch the latest version
>> of Rails.
>>
>> ---Brett.
>>
>> On Mon, Oct 10, 2011 at 2:01 PM, Stefan Frey <ste...@we...> wrote:
>> > Erik:
>> > you are right 1.5.1+ is correct, my train of thought got sidetracked.
>> >
>> > I was thinking about that too, as changing the version number is the only
>> > remaining manual task to publish a new release.
>> >
>> > However there will always the need to update the wiki and html pages, so
>> > it still requires manually intervention.
>> >
>> > I am considering adding webstart support (in addition to the file
>> > releases - not as an replacement), but I want like to know the opinions
>> > of the others about that?
>> >
>> > Stefan
>> >
>> >> I have no opinion on whether or not to put branches in the repo, as I
>> >> ignore them all (so far). However, I would like to see a correct (if
>> >> temporary) version number in the master Game.xml, so that the
>> >> approximate version of saved files can be identified. In my opinion
>> >> that should be 1.5.1+, literally: 1.5.1 and more.
>> >> (A build number would be even better, once we have managed nightly or
>> >> weekly builds. Would it be possible to have the code retrieve the latest
>> >> commit hash?)
>> >>
>> >> Erik.
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------
>> >> --- --- All the data continuously generated in your IT infrastructure
>> >> contains a definitive record of customers, application performance,
>> >> security threats, fraudulent activity and more. Splunk takes this data
>> >> and makes sense of it. Business sense. IT sense. Common sense.
>> >> http://p.sf.net/sfu/splunk-d2dcopy1
>> >> _______________________________________________
>> >> Rails-devel mailing list
>> >> Rai...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> >
>> > -------------------------------------------------------------------------
>> > ----- All the data continuously generated in your IT infrastructure
>> > contains a definitive record of customers, application performance,
>> > security threats, fraudulent activity and more. Splunk takes this data
>> > and makes sense of it. Business sense. IT sense. Common sense.
>> > http://p.sf.net/sfu/splunk-d2dcopy1
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ---------------------------------------------------------------------------
>> --- All the data continuously generated in your IT infrastructure contains
>> a definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 18GA "gray towns" not counted as cities

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

I took the liberty to add the completed game to the test game suite, as we had 
no example game of 18GA so far.

This reminds me that we still have no finished game of 1851, 18Kaas and 18TN 
so far. Could anyone contribute a save file?

Stefan


On Friday, October 07, 2011 11:43:42 pm Adam Badura wrote:
> In the attached save G&F is about to make its OR turn. Don’t lay any tile
> nor place any station. Just run. 6T (its only train) makes a route of 8
> stops. It seems the gray border towns are not counted as cities (while
> they should).
> 
> We noticed this effect (in other companies too) after entering phase 5. But
> its possible that either we just missed it earlier or the tracks and
> trains were setup so that such routes were not possible anyway.
> 
> I looked into tiles XML for 18GA and even tried to change those to Twons
> but it seemed it didn’t help. Yet I might have done it the wrong way.
> 
> Adam Badura

Re: [Rails-devel] Rails 1.5.1 available

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

I have pushed the Rails1.5.x branch and the Rails 1.5.1 tag to the repo.

On Monday, October 10, 2011 08:04:03 pm brett lentz wrote:
> It's far more important to me that each release is accessible from the
> repo. How it achieves that is totally negotiable.
> 
> Personally, because you and Erik are far more active in the project
> than I am, I'm willing to give your preferences a bit more weight than
> mine. ;-)
> 
> IMO, it's easier to leave master as the lineage of stable changes and
> do any new development in (usually local) branches that can be merged
> into the stable trunk when they're ready.
> 
> In git, branches and tags are both very very cheap (and fast), unlike
> SVN. So, if you want to have all development happen in master, then
> branch off for stable releases, we can do that too.
> 
> 
> ---Brett

Re: [Rails-devel] Rails 1.5.1 available

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

Do you remember what the main obstacle was? I suspect the 
custom made classloader?

On Monday, October 10, 2011 08:05:20 pm brett lentz wrote:
> I looked at creating a JNLP several years ago, but couldn't really
> make heads or tails of the process.
> 
> If you can make it happen, that'd be awesome. I'd love to have a link
> on the website that people can click on to launch the latest version
> of Rails.
> 
> ---Brett.
> 
> On Mon, Oct 10, 2011 at 2:01 PM, Stefan Frey <ste...@we...> wrote:
> > Erik:
> > you are right 1.5.1+ is correct, my train of thought got sidetracked.
> > 
> > I was thinking about that too, as changing the version number is the only
> > remaining manual task to publish a new release.
> > 
> > However there will always the need to update the wiki and html pages, so
> > it still requires manually intervention.
> > 
> > I am considering adding webstart support (in addition to the file
> > releases - not as an replacement), but I want like to know the opinions
> > of the others about that?
> > 
> > Stefan
> > 
> >> I have no opinion on whether or not to put branches in the repo, as I
> >> ignore them all (so far). However, I would like to see a correct (if
> >> temporary) version number in the master Game.xml, so that the
> >> approximate version of saved files can be identified. In my opinion
> >> that should be 1.5.1+, literally: 1.5.1 and more.
> >> (A build number would be even better, once we have managed nightly or
> >> weekly builds. Would it be possible to have the code retrieve the latest
> >> commit hash?)
> >> 
> >> Erik.
> >> 
> >> 
> >> 
> >> 
> >> ------------------------------------------------------------------------
> >> --- --- All the data continuously generated in your IT infrastructure
> >> contains a definitive record of customers, application performance,
> >> security threats, fraudulent activity and more. Splunk takes this data
> >> and makes sense of it. Business sense. IT sense. Common sense.
> >> http://p.sf.net/sfu/splunk-d2dcopy1
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> > -------------------------------------------------------------------------
> > ----- All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity and more. Splunk takes this data
> > and makes sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure contains
> a definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rails 1.5.1 available

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

> 
> It's far more important to me that each release is accessible from the
> repo. How it achieves that is totally negotiable.
> 
> Personally, because you and Erik are far more active in the project
> than I am, I'm willing to give your preferences a bit more weight than
> mine. ;-)
> 
> IMO, it's easier to leave master as the lineage of stable changes and
> do any new development in (usually local) branches that can be merged
> into the stable trunk when they're ready.
> 
> In git, branches and tags are both very very cheap (and fast), unlike
> SVN. So, if you want to have all development happen in master, then
> branch off for stable releases, we can do that too.

I understood that for Erik the latter is the preferred choice. And I do not 
mind to manually pick the fixes into a separate branch at the time of release.
So everyone can contribute simply to the master and does not have to care if 
where to push depending if it is a bug-fix or a new development. The only  
thing to ensure is that the master branch compiles and runs after each commit.

Substantial changes have still should be done inside separate branches, like 
my start of refactoring some parts in the Rails 2.0 branch.
Stefan

Re: [Rails-devel] Rails 1.5.1 available

[brett l. <bre...@gm...>]

I looked at creating a JNLP several years ago, but couldn't really
make heads or tails of the process.

If you can make it happen, that'd be awesome. I'd love to have a link
on the website that people can click on to launch the latest version
of Rails.

---Brett.



On Mon, Oct 10, 2011 at 2:01 PM, Stefan Frey <ste...@we...> wrote:
> Erik:
> you are right 1.5.1+ is correct, my train of thought got sidetracked.
>
> I was thinking about that too, as changing the version number is the only
> remaining manual task to publish a new release.
>
> However there will always the need to update the wiki and html pages, so it
> still requires manually intervention.
>
> I am considering adding webstart support (in addition to the file releases -
> not as an replacement), but I want like to know the opinions of the others
> about that?
>
> Stefan
>
>
>>
>> I have no opinion on whether or not to put branches in the repo, as I
>> ignore them all (so far). However, I would like to see a correct (if
>> temporary) version number in the master Game.xml, so that the approximate
>> version of saved files can be identified. In my opinion that should be
>> 1.5.1+, literally: 1.5.1 and more.
>> (A build number would be even better, once we have managed nightly or
>> weekly builds. Would it be possible to have the code retrieve the latest
>> commit hash?)
>>
>> Erik.
>>
>>
>>
>>
>> ---------------------------------------------------------------------------
>> --- All the data continuously generated in your IT infrastructure contains
>> a definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Rails 1.5.1 available

[brett l. <bre...@gm...>]

On Mon, Oct 10, 2011 at 1:55 PM, Stefan Frey <ste...@we...> wrote:
> To clarify  one detail first:
>> > * My e-mail to Erik was asking if there is any interest in uploading a
>> > Rails 1.5.x branch to the repo. The advantage is that this also uploads
>> > the 1.5.1.tag. Disadvantage is that it would add a branch to the repo
>> > which should not be used for developing. And it seems that I would have
>> > to add new branches with every 1.y release to allow for bug-fixes to
>> > that release.
>
>> This needs to be a discussion for all of rails-devel to comment on.
>> While you and Erik are the primary contributors, this sort of change
>> affects everyone and so everyone should have the opportunity to
>> comment on something that will potentially affect them.
>
> This e-mail mentioned above was sent to the devel list, I only used the name
> Erik as the addressee of the mail in the first line.
>
> However I think we are not far away from each other.
>
> Seems that there are two issues where we differ:
>
> A) Publishing the Rails 1.5.x branch
> I know that for a open source project everything should be open to the public.
> But as the commits going into Rails 1.5.1 is a subset of the public commits
> there is nothing material missing inside the repo.
> But as my initial e-mail expressed I am really undecided on this issue, so I
> will follow your advice and publish my Rails 1.5.x branch to the repo.
> By definition I have nothing to hide here ;-)
> But everyone keep in mind that you should not use that branch instead code
> against master.
>
> B) Publishing only bug-fixes
> Here I think we differ a little more: I did the work to pick only those
> commits that are bug-fixes. Simply tagging the head of master in fact is
> easier.
> I did this to improve the likelihood that the bug-fix release fixes more bugs
> than opening new ones. I appreciate those projects that have a clear
> separation of a stable branch with bug-fixes and a development branch with new
> features. As git makes this easy to accomplish I chose that route.
>
> But if you seriously object to this we can go back to the old style for
> release management.
>

It's far more important to me that each release is accessible from the
repo. How it achieves that is totally negotiable.

Personally, because you and Erik are far more active in the project
than I am, I'm willing to give your preferences a bit more weight than
mine. ;-)

IMO, it's easier to leave master as the lineage of stable changes and
do any new development in (usually local) branches that can be merged
into the stable trunk when they're ready.

In git, branches and tags are both very very cheap (and fast), unlike
SVN. So, if you want to have all development happen in master, then
branch off for stable releases, we can do that too.

> Stefan
>

---Brett


>
> On Monday, October 10, 2011 07:32:06 pm brett lentz wrote:
>> Comments inline...
>>
>> On Mon, Oct 10, 2011 at 12:43 PM, Stefan Frey <ste...@we...> wrote:
>> > Brett:
>> > welcome back to the discussion: I hope you finished your cross-country
>> > move successfully.
>>
>> Yup, it was successful (and fun). Now comes the "joy" of unpacking and
>> getting settled. I've got internet and basic amenities, but it'll
>> probably be a month or two before I'm completely done.
>>
>> I'm at least unpacked enough to be able to do everything online that I need
>> to.
>>
>> > I do not fully understand what you critique refers to?
>>
>> My critique refers to the fact that I can't clone the git repo and
>> identify what point in the history 1.5.1 was built from.
>>
>> The 1.5.1 release should be marked as an annotated tag or, in this
>> case, a published branch, so that anybody can build any release they
>> might need. This also helps in tracking down regressions and doing git
>> bisects.
>>
>> Historically, we've never done releases that target specific bugs or
>> specific changes while leaving the "in development" work unpackaged.
>> It's always been shipping out everything when ever we felt that it was
>> stable enough for wider distribution.
>>
>> I'm not opposed to changing that process. I /do/ object to making
>> changes without discussing them adequately, however. I also very much
>> object to re-ordering history so as to make a tag unpublishable.
>>
>> > * Actually I did propose more frequent bug-fix releases already before
>> > the release of 1.5.
>>
>> I saw that. I have no problem with /that/ a release was done. My
>> objection is to /how/ it was done.
>>
>> > * I mailed out yesterday that I would plan a release that only includes
>> > the bug-fixes from the current master (Rails 1.x branch).
>>
>> Yes, but what you didn't say was that because of your plan A) you
>> would not be tagging master in the way it's been done in the past, and
>> B) that you would not be publishing a branch or tag that represents
>> the release.
>>
>> Those are key parts of the release process that were just silently skipped
>> over.
>>
>> > * My e-mail to Erik was asking if there is any interest in uploading a
>> > Rails 1.5.x branch to the repo. The advantage is that this also uploads
>> > the 1.5.1.tag. Disadvantage is that it would add a branch to the repo
>> > which should not be used for developing. And it seems that I would have
>> > to add new branches with every 1.y release to allow for bug-fixes to
>> > that release.
>>
>> This needs to be a discussion for all of rails-devel to comment on.
>> While you and Erik are the primary contributors, this sort of change
>> affects everyone and so everyone should have the opportunity to
>> comment on something that will potentially affect them.
>>
>> We all should be defaulting to open communication and then, if
>> necessary, more detailed discussion can happen off-list.
>>
>> > A possible solution could be to re-order the commits of the master branch
>> > such that the bug-fixes are at bottom (earlier) than the ones that are
>> > adding new stuff. However I do not know how to this and I thought (due
>> > to the never change public history) it is not wise to do so. But if you
>> > have a better solution for it.
>>
>> Git rebase exists to do this, but once the commits are pushed to the
>> public repo, they should not be re-ordered because it will cause
>> problems with everyone else's local repo that has the old history.
>>
>> > But I am open for any (better or different) solution. And to state that
>> > again: The move to git was a great improvement which easily allows doing
>> > such things.
>> >
>> > Stefan
>>
>> I agree. Git allows us to do things in ways that CVS and Subversion
>> were incapable of supporting. I understand that.
>>
>> To be clear, there's no need to change what's been published. Let's
>> just figure out where we go from here.
>>
>> Personally, I'm okay with pushing a tag that's "close" to what we
>> published in 1.5.1. In other words, find the commit that includes all
>> of the fixes that 1.5.1 contained, and tag it. While this will include
>> other work, it's probably "close enough" for maintaining relative
>> consistency with the existing tags. (I'm also open to discussing other
>> options.)
>>
>> ---Brett.
>>
>> > On Monday, October 10, 2011 06:24:21 pm brett lentz wrote:
>> >> If it's a published release, there needs to be a public tag
>> >> referencing it in the git repo.
>> >>
>> >> If you'd like to discuss changes in the release methodology, you
>> >> should do it *before* you do a release with a new methodology.
>> >>
>> >> ---Brett.
>> >>
>> >> On Mon, Oct 10, 2011 at 12:17 PM, Stefan Frey <ste...@we...> wrote:
>> >> > Erik:
>> >> > I have not forgotten to  change the version number, but the master
>> >> > branch is the the developing branch for Rails 1.6. Thus you should
>> >> > change the version number for master to Rails 1.5.9+ or 1.6-
>> >> >
>> >> > I created a local branch for bug-fixes of Rails 1.5 for which I picked
>> >> > those commits that were bug-fixes (using git cherry-pick). Inside this
>> >> > local branch the version number is correctly set to 1.5.1.
>> >> >
>> >> > I would prefer not to upload that local branch to the git repo to
>> >> > avoid that someone starts coding bug-fixes against this (stable)
>> >> > branch instead of the master branch (for the Rails 1.x development).
>> >> > The major disadvantage of that is that the remote repo has no tag for
>> >> > 1.5.1.
>> >> >
>> >> > The other remote branch is for development towards Rails 2.0:
>> >> > I am getting closer to a first compiling version, however it proved
>> >> > that refactoring and a cautious redesigning of the state/model
>> >> > classes to remove the two different types of state/move mechanisms
>> >> > proved to be some more work than expected. However it will make
>> >> > everything around Porfolio and Ownership a little easier: Currently I
>> >> > delete more lines than I add.
>> >> >
>> >> > Stefan
>> >> >
>> >> > On Monday, October 10, 2011 03:10:04 pm Erik Vos wrote:
>> >> >> Stefan,
>> >> >>
>> >> >> It seems you forgot to change the version number in Game.java.  When
>> >> >> I pull, it's still 1.5.
>> >> >> In any case, with my next commit I will change it to 1.5.1+.
>> >> >>
>> >> >> Erik.
>> >> >>
>> >> >> > -----Original Message-----
>> >> >> > From: Stefan Frey [mailto:ste...@we...]
>> >> >> > Sent: Monday, October 10, 2011 11:42 AM
>> >> >> > To: rai...@li...
>> >> >> > Cc: Development list for Rails: an 18xx game; rails-
>> >> >> > us...@li...
>> >> >> > Subject: [Rails-devel] Rails 1.5.1 available
>> >> >> >
>> >> >> > A new bug-fix release 1.5.1 for Rails is available.
>> >> >> >
>> >> >> > Downloads are available at http://rails.sourceforge.net/ or by the
>> >> >> > direct
>> >> >>
>> >> >> link
>> >> >>
>> >> >> > https://sourceforge.net/projects/rails/files/Rails/1.5.1/
>> >> >> >
>> >> >> > It contains:
>> >> >> >
>> >> >> > - Fix to allow laying THB home token if track exists (1856).
>> >> >> > - Fix bug that disallows selling a share after buying one in some
>> >> >> > cases. - Fixed positioning bug of base tokens on corner-facing
>> >> >> > cities. - Fix of revenue calculation: Changed Montgomery and
>> >> >> > Tallahassee to major scoring locations (18GA).
>> >> >> >
>> >> >> > Stefan
>>
>> ---------------------------------------------------------------------------
>> --- All the data continuously generated in your IT infrastructure contains
>> a definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Rails 1.5.1 available

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

Erik:
you are right 1.5.1+ is correct, my train of thought got sidetracked.

I was thinking about that too, as changing the version number is the only 
remaining manual task to publish a new release.

However there will always the need to update the wiki and html pages, so it 
still requires manually intervention.

I am considering adding webstart support (in addition to the file releases - 
not as an replacement), but I want like to know the opinions of the others 
about that?

Stefan


> 
> I have no opinion on whether or not to put branches in the repo, as I
> ignore them all (so far). However, I would like to see a correct (if
> temporary) version number in the master Game.xml, so that the approximate
> version of saved files can be identified. In my opinion that should be
> 1.5.1+, literally: 1.5.1 and more.
> (A build number would be even better, once we have managed nightly or
> weekly builds. Would it be possible to have the code retrieve the latest
> commit hash?)
> 
> Erik.
> 
> 
> 
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure contains
> a definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rails 1.5.1 available

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

To clarify  one detail first: 
> > * My e-mail to Erik was asking if there is any interest in uploading a
> > Rails 1.5.x branch to the repo. The advantage is that this also uploads
> > the 1.5.1.tag. Disadvantage is that it would add a branch to the repo
> > which should not be used for developing. And it seems that I would have
> > to add new branches with every 1.y release to allow for bug-fixes to
> > that release.

> This needs to be a discussion for all of rails-devel to comment on.
> While you and Erik are the primary contributors, this sort of change
> affects everyone and so everyone should have the opportunity to
> comment on something that will potentially affect them.

This e-mail mentioned above was sent to the devel list, I only used the name 
Erik as the addressee of the mail in the first line.

However I think we are not far away from each other.

Seems that there are two issues where we differ:

A) Publishing the Rails 1.5.x branch
I know that for a open source project everything should be open to the public. 
But as the commits going into Rails 1.5.1 is a subset of the public commits 
there is nothing material missing inside the repo.
But as my initial e-mail expressed I am really undecided on this issue, so I 
will follow your advice and publish my Rails 1.5.x branch to the repo.
By definition I have nothing to hide here ;-)
But everyone keep in mind that you should not use that branch instead code 
against master.

B) Publishing only bug-fixes
Here I think we differ a little more: I did the work to pick only those 
commits that are bug-fixes. Simply tagging the head of master in fact is 
easier. 
I did this to improve the likelihood that the bug-fix release fixes more bugs 
than opening new ones. I appreciate those projects that have a clear 
separation of a stable branch with bug-fixes and a development branch with new 
features. As git makes this easy to accomplish I chose that route.

But if you seriously object to this we can go back to the old style for  
release management.

Stefan


On Monday, October 10, 2011 07:32:06 pm brett lentz wrote:
> Comments inline...
> 
> On Mon, Oct 10, 2011 at 12:43 PM, Stefan Frey <ste...@we...> wrote:
> > Brett:
> > welcome back to the discussion: I hope you finished your cross-country
> > move successfully.
> 
> Yup, it was successful (and fun). Now comes the "joy" of unpacking and
> getting settled. I've got internet and basic amenities, but it'll
> probably be a month or two before I'm completely done.
> 
> I'm at least unpacked enough to be able to do everything online that I need
> to.
> 
> > I do not fully understand what you critique refers to?
> 
> My critique refers to the fact that I can't clone the git repo and
> identify what point in the history 1.5.1 was built from.
> 
> The 1.5.1 release should be marked as an annotated tag or, in this
> case, a published branch, so that anybody can build any release they
> might need. This also helps in tracking down regressions and doing git
> bisects.
> 
> Historically, we've never done releases that target specific bugs or
> specific changes while leaving the "in development" work unpackaged.
> It's always been shipping out everything when ever we felt that it was
> stable enough for wider distribution.
> 
> I'm not opposed to changing that process. I /do/ object to making
> changes without discussing them adequately, however. I also very much
> object to re-ordering history so as to make a tag unpublishable.
> 
> > * Actually I did propose more frequent bug-fix releases already before
> > the release of 1.5.
> 
> I saw that. I have no problem with /that/ a release was done. My
> objection is to /how/ it was done.
> 
> > * I mailed out yesterday that I would plan a release that only includes
> > the bug-fixes from the current master (Rails 1.x branch).
> 
> Yes, but what you didn't say was that because of your plan A) you
> would not be tagging master in the way it's been done in the past, and
> B) that you would not be publishing a branch or tag that represents
> the release.
> 
> Those are key parts of the release process that were just silently skipped
> over.
> 
> > * My e-mail to Erik was asking if there is any interest in uploading a
> > Rails 1.5.x branch to the repo. The advantage is that this also uploads
> > the 1.5.1.tag. Disadvantage is that it would add a branch to the repo
> > which should not be used for developing. And it seems that I would have
> > to add new branches with every 1.y release to allow for bug-fixes to
> > that release.
> 
> This needs to be a discussion for all of rails-devel to comment on.
> While you and Erik are the primary contributors, this sort of change
> affects everyone and so everyone should have the opportunity to
> comment on something that will potentially affect them.
> 
> We all should be defaulting to open communication and then, if
> necessary, more detailed discussion can happen off-list.
> 
> > A possible solution could be to re-order the commits of the master branch
> > such that the bug-fixes are at bottom (earlier) than the ones that are
> > adding new stuff. However I do not know how to this and I thought (due
> > to the never change public history) it is not wise to do so. But if you
> > have a better solution for it.
> 
> Git rebase exists to do this, but once the commits are pushed to the
> public repo, they should not be re-ordered because it will cause
> problems with everyone else's local repo that has the old history.
> 
> > But I am open for any (better or different) solution. And to state that
> > again: The move to git was a great improvement which easily allows doing
> > such things.
> > 
> > Stefan
> 
> I agree. Git allows us to do things in ways that CVS and Subversion
> were incapable of supporting. I understand that.
> 
> To be clear, there's no need to change what's been published. Let's
> just figure out where we go from here.
> 
> Personally, I'm okay with pushing a tag that's "close" to what we
> published in 1.5.1. In other words, find the commit that includes all
> of the fixes that 1.5.1 contained, and tag it. While this will include
> other work, it's probably "close enough" for maintaining relative
> consistency with the existing tags. (I'm also open to discussing other
> options.)
> 
> ---Brett.
> 
> > On Monday, October 10, 2011 06:24:21 pm brett lentz wrote:
> >> If it's a published release, there needs to be a public tag
> >> referencing it in the git repo.
> >> 
> >> If you'd like to discuss changes in the release methodology, you
> >> should do it *before* you do a release with a new methodology.
> >> 
> >> ---Brett.
> >> 
> >> On Mon, Oct 10, 2011 at 12:17 PM, Stefan Frey <ste...@we...> wrote:
> >> > Erik:
> >> > I have not forgotten to  change the version number, but the master
> >> > branch is the the developing branch for Rails 1.6. Thus you should
> >> > change the version number for master to Rails 1.5.9+ or 1.6-
> >> > 
> >> > I created a local branch for bug-fixes of Rails 1.5 for which I picked
> >> > those commits that were bug-fixes (using git cherry-pick). Inside this
> >> > local branch the version number is correctly set to 1.5.1.
> >> > 
> >> > I would prefer not to upload that local branch to the git repo to
> >> > avoid that someone starts coding bug-fixes against this (stable)
> >> > branch instead of the master branch (for the Rails 1.x development).
> >> > The major disadvantage of that is that the remote repo has no tag for
> >> > 1.5.1.
> >> > 
> >> > The other remote branch is for development towards Rails 2.0:
> >> > I am getting closer to a first compiling version, however it proved
> >> > that refactoring and a cautious redesigning of the state/model
> >> > classes to remove the two different types of state/move mechanisms
> >> > proved to be some more work than expected. However it will make
> >> > everything around Porfolio and Ownership a little easier: Currently I
> >> > delete more lines than I add.
> >> > 
> >> > Stefan
> >> > 
> >> > On Monday, October 10, 2011 03:10:04 pm Erik Vos wrote:
> >> >> Stefan,
> >> >> 
> >> >> It seems you forgot to change the version number in Game.java.  When
> >> >> I pull, it's still 1.5.
> >> >> In any case, with my next commit I will change it to 1.5.1+.
> >> >> 
> >> >> Erik.
> >> >> 
> >> >> > -----Original Message-----
> >> >> > From: Stefan Frey [mailto:ste...@we...]
> >> >> > Sent: Monday, October 10, 2011 11:42 AM
> >> >> > To: rai...@li...
> >> >> > Cc: Development list for Rails: an 18xx game; rails-
> >> >> > us...@li...
> >> >> > Subject: [Rails-devel] Rails 1.5.1 available
> >> >> > 
> >> >> > A new bug-fix release 1.5.1 for Rails is available.
> >> >> > 
> >> >> > Downloads are available at http://rails.sourceforge.net/ or by the
> >> >> > direct
> >> >> 
> >> >> link
> >> >> 
> >> >> > https://sourceforge.net/projects/rails/files/Rails/1.5.1/
> >> >> > 
> >> >> > It contains:
> >> >> > 
> >> >> > - Fix to allow laying THB home token if track exists (1856).
> >> >> > - Fix bug that disallows selling a share after buying one in some
> >> >> > cases. - Fixed positioning bug of base tokens on corner-facing
> >> >> > cities. - Fix of revenue calculation: Changed Montgomery and
> >> >> > Tallahassee to major scoring locations (18GA).
> >> >> > 
> >> >> > Stefan
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure contains
> a definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rails 1.5.1 available

[Erik V. <eri...@xs...>]

> > * My e-mail to Erik was asking if there is any interest in uploading a
> > Rails 1.5.x branch to the repo. The advantage is that this also
> > uploads the 1.5.1.tag. Disadvantage is that it would add a branch to
> > the repo which should not be used for developing. And it seems that I
> > would have to add new branches with every 1.y release to allow for bug-
> fixes to that release.
> >
> 
> This needs to be a discussion for all of rails-devel to comment on.
> While you and Erik are the primary contributors, this sort of change affects
> everyone and so everyone should have the opportunity to comment on
> something that will potentially affect them.

I have no opinion on whether or not to put branches in the repo, as I ignore them all (so far).  
However, I would like to see a correct (if temporary) version number in the master Game.xml, so that the approximate version of saved files can be identified.
In my opinion that should be 1.5.1+, literally: 1.5.1 and more.
(A build number would be even better, once we have managed nightly or weekly builds. Would it be possible to have the code retrieve the latest commit hash?)

Erik.

Re: [Rails-devel] Rails 1.5.1 available

[brett l. <bre...@gm...>]

Comments inline...

On Mon, Oct 10, 2011 at 12:43 PM, Stefan Frey <ste...@we...> wrote:
> Brett:
> welcome back to the discussion: I hope you finished your cross-country move
> successfully.
>

Yup, it was successful (and fun). Now comes the "joy" of unpacking and
getting settled. I've got internet and basic amenities, but it'll
probably be a month or two before I'm completely done.

I'm at least unpacked enough to be able to do everything online that I need to.

> I do not fully understand what you critique refers to?
>

My critique refers to the fact that I can't clone the git repo and
identify what point in the history 1.5.1 was built from.

The 1.5.1 release should be marked as an annotated tag or, in this
case, a published branch, so that anybody can build any release they
might need. This also helps in tracking down regressions and doing git
bisects.

Historically, we've never done releases that target specific bugs or
specific changes while leaving the "in development" work unpackaged.
It's always been shipping out everything when ever we felt that it was
stable enough for wider distribution.

I'm not opposed to changing that process. I /do/ object to making
changes without discussing them adequately, however. I also very much
object to re-ordering history so as to make a tag unpublishable.

> * Actually I did propose more frequent bug-fix releases already before the
> release of 1.5.
>

I saw that. I have no problem with /that/ a release was done. My
objection is to /how/ it was done.

> * I mailed out yesterday that I would plan a release that only includes the
> bug-fixes from the current master (Rails 1.x branch).
>

Yes, but what you didn't say was that because of your plan A) you
would not be tagging master in the way it's been done in the past, and
B) that you would not be publishing a branch or tag that represents
the release.

Those are key parts of the release process that were just silently skipped over.

> * My e-mail to Erik was asking if there is any interest in uploading a Rails
> 1.5.x branch to the repo. The advantage is that this also uploads the
> 1.5.1.tag. Disadvantage is that it would add a branch to the repo which should
> not be used for developing. And it seems that I would have to add new branches
> with every 1.y release to allow for bug-fixes to that release.
>

This needs to be a discussion for all of rails-devel to comment on.
While you and Erik are the primary contributors, this sort of change
affects everyone and so everyone should have the opportunity to
comment on something that will potentially affect them.

We all should be defaulting to open communication and then, if
necessary, more detailed discussion can happen off-list.

> A possible solution could be to re-order the commits of the master branch such
> that the bug-fixes are at bottom (earlier) than the ones that are adding new
> stuff. However I do not know how to this and I thought (due to the never
> change public history) it is not wise to do so. But if you have a better
> solution for it.
>

Git rebase exists to do this, but once the commits are pushed to the
public repo, they should not be re-ordered because it will cause
problems with everyone else's local repo that has the old history.

> But I am open for any (better or different) solution. And to state that again:
> The move to git was a great improvement which easily allows doing such things.
>
> Stefan
>

I agree. Git allows us to do things in ways that CVS and Subversion
were incapable of supporting. I understand that.

To be clear, there's no need to change what's been published. Let's
just figure out where we go from here.

Personally, I'm okay with pushing a tag that's "close" to what we
published in 1.5.1. In other words, find the commit that includes all
of the fixes that 1.5.1 contained, and tag it. While this will include
other work, it's probably "close enough" for maintaining relative
consistency with the existing tags. (I'm also open to discussing other
options.)

---Brett.


>
>
> On Monday, October 10, 2011 06:24:21 pm brett lentz wrote:
>> If it's a published release, there needs to be a public tag
>> referencing it in the git repo.
>>
>> If you'd like to discuss changes in the release methodology, you
>> should do it *before* you do a release with a new methodology.
>>
>> ---Brett.
>>
>> On Mon, Oct 10, 2011 at 12:17 PM, Stefan Frey <ste...@we...> wrote:
>> > Erik:
>> > I have not forgotten to  change the version number, but the master branch
>> > is the the developing branch for Rails 1.6. Thus you should change the
>> > version number for master to Rails 1.5.9+ or 1.6-
>> >
>> > I created a local branch for bug-fixes of Rails 1.5 for which I picked
>> > those commits that were bug-fixes (using git cherry-pick). Inside this
>> > local branch the version number is correctly set to 1.5.1.
>> >
>> > I would prefer not to upload that local branch to the git repo to avoid
>> > that someone starts coding bug-fixes against this (stable) branch
>> > instead of the master branch (for the Rails 1.x development). The major
>> > disadvantage of that is that the remote repo has no tag for 1.5.1.
>> >
>> > The other remote branch is for development towards Rails 2.0:
>> > I am getting closer to a first compiling version, however it proved that
>> > refactoring and a cautious redesigning of the state/model classes to
>> > remove the two different types of state/move mechanisms proved to be
>> > some more work than expected. However it will make everything around
>> > Porfolio and Ownership a little easier: Currently I delete more lines
>> > than I add.
>> >
>> > Stefan
>> >
>> > On Monday, October 10, 2011 03:10:04 pm Erik Vos wrote:
>> >> Stefan,
>> >>
>> >> It seems you forgot to change the version number in Game.java.  When I
>> >> pull, it's still 1.5.
>> >> In any case, with my next commit I will change it to 1.5.1+.
>> >>
>> >> Erik.
>> >>
>> >> > -----Original Message-----
>> >> > From: Stefan Frey [mailto:ste...@we...]
>> >> > Sent: Monday, October 10, 2011 11:42 AM
>> >> > To: rai...@li...
>> >> > Cc: Development list for Rails: an 18xx game; rails-
>> >> > us...@li...
>> >> > Subject: [Rails-devel] Rails 1.5.1 available
>> >> >
>> >> > A new bug-fix release 1.5.1 for Rails is available.
>> >> >
>> >> > Downloads are available at http://rails.sourceforge.net/ or by the
>> >> > direct
>> >>
>> >> link
>> >>
>> >> > https://sourceforge.net/projects/rails/files/Rails/1.5.1/
>> >> >
>> >> > It contains:
>> >> >
>> >> > - Fix to allow laying THB home token if track exists (1856).
>> >> > - Fix bug that disallows selling a share after buying one in some
>> >> > cases. - Fixed positioning bug of base tokens on corner-facing
>> >> > cities. - Fix of revenue calculation: Changed Montgomery and
>> >> > Tallahassee to major scoring locations (18GA).
>> >> >
>> >> > Stefan
>> >>

Re: [Rails-devel] Rails 1.5.1 available

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

Brett:
welcome back to the discussion: I hope you finished your cross-country move 
successfully. 

I do not fully understand what you critique refers to?

* Actually I did propose more frequent bug-fix releases already before the 
release of 1.5.

* I mailed out yesterday that I would plan a release that only includes the 
bug-fixes from the current master (Rails 1.x branch). 

* My e-mail to Erik was asking if there is any interest in uploading a Rails 
1.5.x branch to the repo. The advantage is that this also uploads the 
1.5.1.tag. Disadvantage is that it would add a branch to the repo which should 
not be used for developing. And it seems that I would have to add new branches 
with every 1.y release to allow for bug-fixes to that release.

A possible solution could be to re-order the commits of the master branch such 
that the bug-fixes are at bottom (earlier) than the ones that are adding new 
stuff. However I do not know how to this and I thought (due to the never 
change public history) it is not wise to do so. But if you have a better 
solution for it.
 
But I am open for any (better or different) solution. And to state that again: 
The move to git was a great improvement which easily allows doing such things.

Stefan



On Monday, October 10, 2011 06:24:21 pm brett lentz wrote:
> If it's a published release, there needs to be a public tag
> referencing it in the git repo.
> 
> If you'd like to discuss changes in the release methodology, you
> should do it *before* you do a release with a new methodology.
> 
> ---Brett.
> 
> On Mon, Oct 10, 2011 at 12:17 PM, Stefan Frey <ste...@we...> wrote:
> > Erik:
> > I have not forgotten to  change the version number, but the master branch
> > is the the developing branch for Rails 1.6. Thus you should change the
> > version number for master to Rails 1.5.9+ or 1.6-
> > 
> > I created a local branch for bug-fixes of Rails 1.5 for which I picked
> > those commits that were bug-fixes (using git cherry-pick). Inside this
> > local branch the version number is correctly set to 1.5.1.
> > 
> > I would prefer not to upload that local branch to the git repo to avoid
> > that someone starts coding bug-fixes against this (stable) branch
> > instead of the master branch (for the Rails 1.x development). The major
> > disadvantage of that is that the remote repo has no tag for 1.5.1.
> > 
> > The other remote branch is for development towards Rails 2.0:
> > I am getting closer to a first compiling version, however it proved that
> > refactoring and a cautious redesigning of the state/model classes to
> > remove the two different types of state/move mechanisms proved to be
> > some more work than expected. However it will make everything around
> > Porfolio and Ownership a little easier: Currently I delete more lines
> > than I add.
> > 
> > Stefan
> > 
> > On Monday, October 10, 2011 03:10:04 pm Erik Vos wrote:
> >> Stefan,
> >> 
> >> It seems you forgot to change the version number in Game.java.  When I
> >> pull, it's still 1.5.
> >> In any case, with my next commit I will change it to 1.5.1+.
> >> 
> >> Erik.
> >> 
> >> > -----Original Message-----
> >> > From: Stefan Frey [mailto:ste...@we...]
> >> > Sent: Monday, October 10, 2011 11:42 AM
> >> > To: rai...@li...
> >> > Cc: Development list for Rails: an 18xx game; rails-
> >> > us...@li...
> >> > Subject: [Rails-devel] Rails 1.5.1 available
> >> > 
> >> > A new bug-fix release 1.5.1 for Rails is available.
> >> > 
> >> > Downloads are available at http://rails.sourceforge.net/ or by the
> >> > direct
> >> 
> >> link
> >> 
> >> > https://sourceforge.net/projects/rails/files/Rails/1.5.1/
> >> > 
> >> > It contains:
> >> > 
> >> > - Fix to allow laying THB home token if track exists (1856).
> >> > - Fix bug that disallows selling a share after buying one in some
> >> > cases. - Fixed positioning bug of base tokens on corner-facing
> >> > cities. - Fix of revenue calculation: Changed Montgomery and
> >> > Tallahassee to major scoring locations (18GA).
> >> > 
> >> > Stefan
> >> 
> >> ------------------------------------------------------------------------
> >> --- - --
> >> 
> >> > All the data continuously generated in your IT infrastructure contains
> >> > a definitive record of customers, application performance, security
> >> > threats, fraudulent activity and more. Splunk takes this data and
> >> > makes sense of
> >> 
> >> it.
> >> 
> >> > Business sense. IT sense. Common sense.
> >> > http://p.sf.net/sfu/splunk-d2dcopy1
> >> > _______________________________________________
> >> > Rails-devel mailing list
> >> > Rai...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >> 
> >> ------------------------------------------------------------------------
> >> --- --- All the data continuously generated in your IT infrastructure
> >> contains a definitive record of customers, application performance,
> >> security threats, fraudulent activity and more. Splunk takes this data
> >> and makes sense of it. Business sense. IT sense. Common sense.
> >> http://p.sf.net/sfu/splunk-d2dcopy1
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> > 
> > -------------------------------------------------------------------------
> > ----- All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity and more. Splunk takes this data
> > and makes sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure contains
> a definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rails 1.5.1 available

[Erik V. <eri...@xs...>]

Stefan,

Thanks, it's clear now.
But I would prefer to leave the next version number undecided, be it 1.5.2
or 1.6, until we have a clue what changes it will have. 
So I prefer to stick with 1.5.1+ for the master branch. (I'm only pushing
and pulling master.)

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, October 10, 2011 6:18 PM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Rails 1.5.1 available
> 
> Erik:
> I have not forgotten to  change the version number, but the master branch
is
> the the developing branch for Rails 1.6. Thus you should change the
version
> number for master to Rails 1.5.9+ or 1.6-
> 
> I created a local branch for bug-fixes of Rails 1.5 for which I picked
those
> commits that were bug-fixes (using git cherry-pick). Inside this local
branch
> the version number is correctly set to 1.5.1.
> 
> I would prefer not to upload that local branch to the git repo to avoid
that
> someone starts coding bug-fixes against this (stable) branch instead of
the
> master branch (for the Rails 1.x development). The major disadvantage of
> that is that the remote repo has no tag for 1.5.1.
> 
> The other remote branch is for development towards Rails 2.0:
> I am getting closer to a first compiling version, however it proved that
> refactoring and a cautious redesigning of the state/model classes to
remove
> the two different types of state/move mechanisms proved to be some more
> work than expected. However it will make everything around Porfolio and
> Ownership a little easier: Currently I delete more lines than I add.
> 
> Stefan
> 
> 
> 
> 
> 
> 
> 
> On Monday, October 10, 2011 03:10:04 pm Erik Vos wrote:
> > Stefan,
> >
> > It seems you forgot to change the version number in Game.java.  When I
> > pull, it's still 1.5.
> > In any case, with my next commit I will change it to 1.5.1+.
> >
> > Erik.
> >
> > > -----Original Message-----
> > > From: Stefan Frey [mailto:ste...@we...]
> > > Sent: Monday, October 10, 2011 11:42 AM
> > > To: rai...@li...
> > > Cc: Development list for Rails: an 18xx game; rails-
> > > us...@li...
> > > Subject: [Rails-devel] Rails 1.5.1 available
> > >
> > > A new bug-fix release 1.5.1 for Rails is available.
> > >
> > > Downloads are available at http://rails.sourceforge.net/ or by the
> > > direct
> >
> > link
> >
> > > https://sourceforge.net/projects/rails/files/Rails/1.5.1/
> > >
> > > It contains:
> > >
> > > - Fix to allow laying THB home token if track exists (1856).
> > > - Fix bug that disallows selling a share after buying one in some
cases.
> > > - Fixed positioning bug of base tokens on corner-facing cities.
> > > - Fix of revenue calculation: Changed Montgomery and Tallahassee to
> > > major scoring locations (18GA).
> > >
> > > Stefan
> >
> > ----------------------------------------------------------------------
> > -----
> > - --
> >
> > > All the data continuously generated in your IT infrastructure
> > > contains a definitive record of customers, application performance,
> > > security threats, fraudulent activity and more. Splunk takes this
> > > data and makes sense of
> >
> > it.
> >
> > > Business sense. IT sense. Common sense.
> > > http://p.sf.net/sfu/splunk-d2dcopy1
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > --- All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity and more. Splunk takes this data
> > and makes sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>
----------------------------------------------------------------------------
--
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity and more. Splunk takes this data and makes sense of
it.
> Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rails 1.5.1 available

[brett l. <bre...@gm...>]

If it's a published release, there needs to be a public tag
referencing it in the git repo.

If you'd like to discuss changes in the release methodology, you
should do it *before* you do a release with a new methodology.

---Brett.



On Mon, Oct 10, 2011 at 12:17 PM, Stefan Frey <ste...@we...> wrote:
> Erik:
> I have not forgotten to  change the version number, but the master branch is
> the the developing branch for Rails 1.6. Thus you should change the version
> number for master to Rails 1.5.9+ or 1.6-
>
> I created a local branch for bug-fixes of Rails 1.5 for which I picked those
> commits that were bug-fixes (using git cherry-pick). Inside this local branch
> the version number is correctly set to 1.5.1.
>
> I would prefer not to upload that local branch to the git repo to avoid that
> someone starts coding bug-fixes against this (stable) branch instead of the
> master branch (for the Rails 1.x development). The major disadvantage of that
> is that the remote repo has no tag for 1.5.1.
>
> The other remote branch is for development towards Rails 2.0:
> I am getting closer to a first compiling version, however it proved that
> refactoring and a cautious redesigning of the state/model classes to remove
> the two different types of state/move mechanisms proved to be some more work
> than expected. However it will make everything around Porfolio and Ownership a
> little easier: Currently I delete more lines than I add.
>
> Stefan
>
>
>
>
>
>
>
> On Monday, October 10, 2011 03:10:04 pm Erik Vos wrote:
>> Stefan,
>>
>> It seems you forgot to change the version number in Game.java.  When I
>> pull, it's still 1.5.
>> In any case, with my next commit I will change it to 1.5.1+.
>>
>> Erik.
>>
>> > -----Original Message-----
>> > From: Stefan Frey [mailto:ste...@we...]
>> > Sent: Monday, October 10, 2011 11:42 AM
>> > To: rai...@li...
>> > Cc: Development list for Rails: an 18xx game; rails-
>> > us...@li...
>> > Subject: [Rails-devel] Rails 1.5.1 available
>> >
>> > A new bug-fix release 1.5.1 for Rails is available.
>> >
>> > Downloads are available at http://rails.sourceforge.net/ or by the direct
>>
>> link
>>
>> > https://sourceforge.net/projects/rails/files/Rails/1.5.1/
>> >
>> > It contains:
>> >
>> > - Fix to allow laying THB home token if track exists (1856).
>> > - Fix bug that disallows selling a share after buying one in some cases.
>> > - Fixed positioning bug of base tokens on corner-facing cities.
>> > - Fix of revenue calculation: Changed Montgomery and Tallahassee to major
>> > scoring locations (18GA).
>> >
>> > Stefan
>>
>> ---------------------------------------------------------------------------
>> - --
>>
>> > All the data continuously generated in your IT infrastructure contains a
>> > definitive record of customers, application performance, security
>> > threats, fraudulent activity and more. Splunk takes this data and makes
>> > sense of
>>
>> it.
>>
>> > Business sense. IT sense. Common sense.
>> > http://p.sf.net/sfu/splunk-d2dcopy1
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ---------------------------------------------------------------------------
>> --- All the data continuously generated in your IT infrastructure contains
>> a definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Rails 1.5.1 available

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

Erik:
I have not forgotten to  change the version number, but the master branch is 
the the developing branch for Rails 1.6. Thus you should change the version 
number for master to Rails 1.5.9+ or 1.6- 

I created a local branch for bug-fixes of Rails 1.5 for which I picked those 
commits that were bug-fixes (using git cherry-pick). Inside this local branch 
the version number is correctly set to 1.5.1.

I would prefer not to upload that local branch to the git repo to avoid that 
someone starts coding bug-fixes against this (stable) branch instead of the 
master branch (for the Rails 1.x development). The major disadvantage of that 
is that the remote repo has no tag for 1.5.1.

The other remote branch is for development towards Rails 2.0: 
I am getting closer to a first compiling version, however it proved that 
refactoring and a cautious redesigning of the state/model classes to remove 
the two different types of state/move mechanisms proved to be some more work 
than expected. However it will make everything around Porfolio and Ownership a 
little easier: Currently I delete more lines than I add.

Stefan







On Monday, October 10, 2011 03:10:04 pm Erik Vos wrote:
> Stefan,
> 
> It seems you forgot to change the version number in Game.java.  When I
> pull, it's still 1.5.
> In any case, with my next commit I will change it to 1.5.1+.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Monday, October 10, 2011 11:42 AM
> > To: rai...@li...
> > Cc: Development list for Rails: an 18xx game; rails-
> > us...@li...
> > Subject: [Rails-devel] Rails 1.5.1 available
> > 
> > A new bug-fix release 1.5.1 for Rails is available.
> > 
> > Downloads are available at http://rails.sourceforge.net/ or by the direct
> 
> link
> 
> > https://sourceforge.net/projects/rails/files/Rails/1.5.1/
> > 
> > It contains:
> > 
> > - Fix to allow laying THB home token if track exists (1856).
> > - Fix bug that disallows selling a share after buying one in some cases.
> > - Fixed positioning bug of base tokens on corner-facing cities.
> > - Fix of revenue calculation: Changed Montgomery and Tallahassee to major
> > scoring locations (18GA).
> > 
> > Stefan
> 
> ---------------------------------------------------------------------------
> - --
> 
> > All the data continuously generated in your IT infrastructure contains a
> > definitive record of customers, application performance, security
> > threats, fraudulent activity and more. Splunk takes this data and makes
> > sense of
> 
> it.
> 
> > Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2dcopy1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- All the data continuously generated in your IT infrastructure contains
> a definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Rails 1.5.1 available

[Erik V. <eri...@xs...>]

Stefan,

It seems you forgot to change the version number in Game.java.  When I pull,
it's still 1.5.
In any case, with my next commit I will change it to 1.5.1+.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, October 10, 2011 11:42 AM
> To: rai...@li...
> Cc: Development list for Rails: an 18xx game; rails-
> us...@li...
> Subject: [Rails-devel] Rails 1.5.1 available
> 
> A new bug-fix release 1.5.1 for Rails is available.
> 
> Downloads are available at http://rails.sourceforge.net/ or by the direct
link
> https://sourceforge.net/projects/rails/files/Rails/1.5.1/
> 
> It contains:
> 
> - Fix to allow laying THB home token if track exists (1856).
> - Fix bug that disallows selling a share after buying one in some cases.
> - Fixed positioning bug of base tokens on corner-facing cities.
> - Fix of revenue calculation: Changed Montgomery and Tallahassee to major
> scoring locations (18GA).
> 
> Stefan
> 
> 
>
----------------------------------------------------------------------------
--
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity and more. Splunk takes this data and makes sense of
it.
> Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Rails 1.5.1 available

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

A new bug-fix release 1.5.1 for Rails is available.

Downloads are available at http://rails.sourceforge.net/ or by the
direct link https://sourceforge.net/projects/rails/files/Rails/1.5.1/

It contains:

- Fix to allow laying THB home token if track exists (1856).
- Fix bug that disallows selling a share after buying one in some cases.
- Fixed positioning bug of base tokens on corner-facing cities.
- Fix of revenue calculation: Changed Montgomery and Tallahassee to major 
scoring locations (18GA).

Stefan

[Rails-devel] Upcoming bug-fixing release 1.5.1

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

I will prepare a new bug-fix release (1.5.1) tonight.
Preferably I will try to create another branch that only contains bug-fixes of 
the current stable release by hand-picking those from all commits to the 
master since the 1.5 tag.
Thus it will not contain the changes required for 1880.
Stefan

Re: [Rails-devel] XML and Java file formatting

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

In a standard setup of Eclipse the formats for .java files should be set 
correctly from Rails-format.xml automatically.

For .xml I checked the setup the preferences of the Rhino add-ons manually 
again and it is set to tabs.

I have no specific preference for spaces/tabs (but if I am forced to choose I 
prefer tabs), however I strongly prefer if adherence to a decision ;-)

Stefan


On Friday, October 07, 2011 04:02:59 pm Erik Vos wrote:
> In my previous mail I mentioned a Perl XML formatter that I have just
> written on the fly and committed to the repository (well, I had written
> such a script before, but could not find it).  I have used it to format
> some recreated Tiles.xml files, and will keep using it for that purpose
> (perhaps for other XML files too, if needed; but XMLBuddy seems to work
> the same).
> 
> On the details, I have settled on the format of the generic Tiles.xml file,
> as it has recently been reformatted by Brett:
> - for indentation: tabs, no spaces (I loathe tabs, but see no point in
> starting an argument about that),
> - newlines only, no CRs (to achieve that on Windows, formatxml.pl uses
> binmode).
> Can we try to standardize this way? I often see redundant whitespace-only
> differences in commits, which is a waste.
> 
> Redundant whitespace-only differences are also often seen in Java source
> code commits. Here I would also propose to standardize on the currently
> most frequent usage, which is:
> - for indentation: spaces, no tabs (after all, in this way I have written
> the majority of the code, and Stefan does it similarly.  I notice that
> Brett uses tabs).
> - newlines only (I don't think that it matters for Java compilers, but this
> is how Eclipse is doing it even on my Windows machine. Brett's machine is
> adding CRs, as it seems to me).
> Please note, that my Eclipse is set to convert all tabs to spaces on saving
> Rails Java files.
> 
> This all is no problem as long as we work on different code packages, but
> some files have several contributors by now.
> 
> I hope this helps.
> 
> Erik.
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------------
> --- All of the data generated in your IT infrastructure is seriously
> valuable. Why? It contains a definitive record of application performance,
> security threats, fraudulent activity, and more. Splunk takes this data
> and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel