Menu
▾
▴
rails-devel — List for discussion of Rails development
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(25) |
Mar
(84) |
Apr
(76) |
May
(25) |
Jun
(1) |
Jul
(28) |
Aug
(23) |
Sep
(50) |
Oct
(46) |
Nov
(65) |
Dec
(76) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(60) |
Feb
(33) |
Mar
(4) |
Apr
(17) |
May
(16) |
Jun
(18) |
Jul
(131) |
Aug
(11) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(5) |
| 2007 |
Jan
(71) |
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(19) |
Jul
(40) |
Aug
(38) |
Sep
(7) |
Oct
(58) |
Nov
|
Dec
(10) |
| 2008 |
Jan
(17) |
Feb
(27) |
Mar
(12) |
Apr
(1) |
May
(50) |
Jun
(10) |
Jul
|
Aug
(15) |
Sep
(24) |
Oct
(64) |
Nov
(115) |
Dec
(47) |
| 2009 |
Jan
(30) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
(4) |
Nov
(132) |
Dec
(93) |
| 2010 |
Jan
(266) |
Feb
(120) |
Mar
(168) |
Apr
(127) |
May
(83) |
Jun
(93) |
Jul
(77) |
Aug
(77) |
Sep
(86) |
Oct
(30) |
Nov
(4) |
Dec
(22) |
| 2011 |
Jan
(48) |
Feb
(81) |
Mar
(198) |
Apr
(174) |
May
(72) |
Jun
(101) |
Jul
(236) |
Aug
(144) |
Sep
(54) |
Oct
(132) |
Nov
(94) |
Dec
(111) |
| 2012 |
Jan
(135) |
Feb
(166) |
Mar
(86) |
Apr
(85) |
May
(137) |
Jun
(83) |
Jul
(54) |
Aug
(29) |
Sep
(49) |
Oct
(37) |
Nov
(8) |
Dec
(6) |
| 2013 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(14) |
May
(5) |
Jun
(15) |
Jul
|
Aug
(38) |
Sep
(44) |
Oct
(45) |
Nov
(40) |
Dec
(23) |
| 2014 |
Jan
(22) |
Feb
(63) |
Mar
(43) |
Apr
(60) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(57) |
Sep
(36) |
Oct
(2) |
Nov
(30) |
Dec
(27) |
| 2015 |
Jan
(5) |
Feb
(2) |
Mar
(14) |
Apr
(3) |
May
|
Jun
(3) |
Jul
(10) |
Aug
(63) |
Sep
(31) |
Oct
(26) |
Nov
(11) |
Dec
(6) |
| 2016 |
Jan
|
Feb
(11) |
Mar
|
Apr
|
May
(1) |
Jun
(16) |
Jul
|
Aug
(4) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(1) |
| 2017 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(20) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(10) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(3) |
Apr
(9) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(4) |
| 2021 |
Jan
(5) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <Dr....@t-...> - 2013-11-14 10:51:28
|
HI Anfrew, i just checked the codebase. The "omission" is still there. And yes that weas somehow intentional by me. Explanation as follows: Tiledesigner was created in the early 2000s. Largest known city at that time was a 4 token city leading to the Junction Type jtQuadrupleCity 1880 now needs cities with 6 connected tokens (Beijing in brown and grey). Theres no reprensentation of that today possible in tiledesigner. We have no source code, however the supporting converting code in rails (branch 1.7.12_1880) supports "jtHextupleCity" and creates the appropriate tile in the internal representation. But Tiledesigner dumps on reading the line with an unknown Junction Type, while its just stating the message you mentioned below. So this can be fixed locally and should only be fixed locally if one is aware of the problems/consequences. A number of tiles for the 1880 variant have been moved to the handmade part anyway, but we need to have Tiledesigner.18t to support the more or less automatic creation process of Tiles.xml. This is not satisfactory itself i have to admit. But can not be avoided in the moment if you dont want to add tile per tile manually to the repository. One could easily add a jtCity in the missing lines and make sure that the faulty tiles dont get automatically promoted but be overwritten by handmade tiles. But to someone not used to the internal workings of the tile creation process (TM Erik Vos :)) will stumble at this point and hope fully now know why that road block is there. I'll add this excerpt to the tile creation on the Wiki also. Kind Regards, and again sorry for the inconveniences. Martin P.s. For curiosity reasons, the 1880 tree is pretty special, what was/is your interest in digging through that ? :) Von: Andrew Miller <A.J...@bc...> An: rai...@li... Betreff: [Rails-devel] Error when opening TileDictionary.18t in TileDesigner.exe Datum: Wed, 13 Nov 2013 16:10:29 +0100 When I try to open TileDictionary.18t, Tile Designer gives the following error: "Identifier expected on line 16328" Looking at line 16328, it seems that that the JunType has removed. This has also happened to line 16660 (tiles 8887 and 8888 respectively). These changes appear to have been made in this commit: https://sourceforge.net/p/rails/code/ci/72277ff2256f2c1a456753422879fefbc48ca91e/ [1] Andrew Links: ------ [1] https://sourceforge.net/p/rails/code/ci/72277ff2256f2c1a456753422879fefbc48ca91e/ |
|
From: <Dr....@t-...> - 2013-11-14 10:11:12
|
Hi Stefan, sounds good and should find its way into the general announcement page of Rails, the wiki and into the Readme imho. Regards, Martin Von: Stefan Frey <ste...@we...> An: Development list for Rails: an 18xx game <rai...@li...> Betreff: [Rails-devel] Specification of implementation levels for different 18xx games in Rails (was: [Rails-users] Bug in 18GA private auction) Datum: Thu, 14 Nov 2013 10:44:51 +0100 Given that some games (1830 and all direct derivatives, 1856, 18EU) are pretty mature and others (1835, 1880) are still in the bug fixing cycle, I suggest a new label for the stable games. Any thoughts about how to name it? "Mature", "Stable"? We have "Fully Playable" (see above) "Partial Playable" (none) "Not Yet Playable" (1870, 1825) "Prototype" (1826, 18Scan, 18VA) "In development" (1837). However I do not know how the three latter categories really differ? Maybe we should have something like: * Fully Playable with qualification: -Mature (Only very few minor bugs to be expected) -Stable (Only minor bugs to be expected, can be fixed easily) -Testing (Major bugs to be expected, can take some time to be resolved) * Partially Playable (All xml files ready, some rules coded, tests possible, but expect not to finish games) * In development (All xml files ready, started coding) * Prototype (Only xml definition files, no coding done so far) Thoughts? Stefan -------- Original Message -------- Subject: Re: [Rails-users] Bug in 18GA private auction Date: Thu, 14 Nov 2013 10:01:02 +0100 From: Stefan Frey <ste...@we... [1]> To: rai...@li... [2] In fact Rails allows both, exclude or include a player from further bidding after a pass: => It depends on the setting "Leave auction on pass" that is set to "No" as default for 18GA. This can be changed at game start. => If I remember correctly this is not defined in the AH version of the 1830 rules. So the option was created for 1830 (default there "No" too) and it exists for all 1830 "clones" or "close derivatives", even if there is a ruling in the derivative rule book. However the default should be set to the wording in that rule book. Justin: nothing to be embarrassed about. Auction rules of 1830 have created various variants over time. The only good thing is that Rails for 1830 is so stable, that it is more likely that the bug is due to the users perception. Some time ago I proposed to introduce another level for those games instead of "fully playable", something like "mature" or "stable" to indicate that there are not many bugs to be expected, compared to what we have for example for 1835 and 1880 currently. Stefan On 11/13/2013 06:17 PM, Justin Rebelo wrote: > Wow. That's embarrassing. Sorry for the bogus report. The players in the > game all agreed it was a bug and I just went straight to filing rather > than reporting. Won't do that again. ;) > > > On Wed, Nov 13, 2013 at 9:15 AM, Jerry Anderson <jer...@ya... [3] > <jer...@ya... [4]>> wrote: > > Not a bug. From the rule book - page 7. > "A player who has passed may bid later, if he gets another turn > before the auction ends." > > *From:* Justin Rebelo <jus...@gm... [5] > <jus...@gm... [6]>> > *To:* rai...@li... [7] > <rai...@li... [8]> > *Sent:* Wednesday, November 13, 2013 9:04 AM > *Subject:* [Rails-users] Bug in 18GA private auction > > Forgive me if this is not the correct place for this. I am involved > in a game of 18GA (using Cotton Port variant map). We are four > players and during the initial private auction encountered a very > minor bug that is probably an easy fix for someone with intimate > knowledge of the code. > > There were three pending bids on the OSO private company and after > the preceding company auction was concluded, the first player to > have a bid chose to pass. The next two players raised the bids and > then the first player (who had already passed) was prompted as the > next active player with the option to bid again or pass. The player > should not be able to re-enter the private auction in this case. > Easy to work around for now. > > Thanks! > Justin > > ------------------------------------------------------------------------------ > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access > Free app hosting. Or install the open source package on any LAMP server. > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! > http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk [9] > _______________________________________________ > Rails-users mailing list > Rai...@li... [10] > <Rai...@li... [11]> > https://lists.sourceforge.net/lists/listinfo/rails-users [12] > > > > > > ------------------------------------------------------------------------------ > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access > Free app hosting. Or install the open source package on any LAMP server. > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! > http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk [13] > > > > _______________________________________________ > Rails-users mailing list > Rai...@li... [14] > https://lists.sourceforge.net/lists/listinfo/rails-users [15] > ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk [16] _______________________________________________ Rails-users mailing list Rai...@li... [17] https://lists.sourceforge.net/lists/listinfo/rails-users [18] ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk [19] _______________________________________________ Rails-devel mailing list Rai...@li... [20] https://lists.sourceforge.net/lists/listinfo/rails-devel [21] Links: ------ [1] javascript:void(0) [2] javascript:void(0) [3] javascript:void(0) [4] javascript:void(0) [5] javascript:void(0) [6] javascript:void(0) [7] javascript:void(0) [8] javascript:void(0) [9] ?ctl=dereferer&to=aHR0cDovL3B1YmFkcy5nLmRvdWJsZWNsaWNrLm5ldC9nYW1wYWQvY2xrP2lkPTYzNDY5NDcxJml1PS80MTQwL29zdGcuY2xrdHJr [10] javascript:void(0) [11] javascript:void(0) [12] ?ctl=dereferer&to=aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcmFpbHMtdXNlcnM%3D [13] ?ctl=dereferer&to=aHR0cDovL3B1YmFkcy5nLmRvdWJsZWNsaWNrLm5ldC9nYW1wYWQvY2xrP2lkPTYzNDY5NDcxJml1PS80MTQwL29zdGcuY2xrdHJr [14] javascript:void(0) [15] ?ctl=dereferer&to=aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcmFpbHMtdXNlcnM%3D [16] ?ctl=dereferer&to=aHR0cDovL3B1YmFkcy5nLmRvdWJsZWNsaWNrLm5ldC9nYW1wYWQvY2xrP2lkPTYzNDY5NDcxJml1PS80MTQwL29zdGcuY2xrdHJr [17] javascript:void(0) [18] ?ctl=dereferer&to=aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcmFpbHMtdXNlcnM%3D [19] ?ctl=dereferer&to=aHR0cDovL3B1YmFkcy5nLmRvdWJsZWNsaWNrLm5ldC9nYW1wYWQvY2xrP2lkPTYzNDY5NDcxJml1PS80MTQwL29zdGcuY2xrdHJr [20] javascript:void(0) [21] ?ctl=dereferer&to=aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcmFpbHMtZGV2ZWw%3D |
|
From: Stefan F. <ste...@we...> - 2013-11-14 09:45:02
|
Given that some games (1830 and all direct derivatives, 1856, 18EU) are pretty mature and others (1835, 1880) are still in the bug fixing cycle, I suggest a new label for the stable games. Any thoughts about how to name it? "Mature", "Stable"? We have "Fully Playable" (see above) "Partial Playable" (none) "Not Yet Playable" (1870, 1825) "Prototype" (1826, 18Scan, 18VA) "In development" (1837). However I do not know how the three latter categories really differ? Maybe we should have something like: * Fully Playable with qualification: -Mature (Only very few minor bugs to be expected) -Stable (Only minor bugs to be expected, can be fixed easily) -Testing (Major bugs to be expected, can take some time to be resolved) * Partially Playable (All xml files ready, some rules coded, tests possible, but expect not to finish games) * In development (All xml files ready, started coding) * Prototype (Only xml definition files, no coding done so far) Thoughts? Stefan -------- Original Message -------- Subject: Re: [Rails-users] Bug in 18GA private auction Date: Thu, 14 Nov 2013 10:01:02 +0100 From: Stefan Frey <ste...@we...> To: rai...@li... In fact Rails allows both, exclude or include a player from further bidding after a pass: => It depends on the setting "Leave auction on pass" that is set to "No" as default for 18GA. This can be changed at game start. => If I remember correctly this is not defined in the AH version of the 1830 rules. So the option was created for 1830 (default there "No" too) and it exists for all 1830 "clones" or "close derivatives", even if there is a ruling in the derivative rule book. However the default should be set to the wording in that rule book. Justin: nothing to be embarrassed about. Auction rules of 1830 have created various variants over time. The only good thing is that Rails for 1830 is so stable, that it is more likely that the bug is due to the users perception. Some time ago I proposed to introduce another level for those games instead of "fully playable", something like "mature" or "stable" to indicate that there are not many bugs to be expected, compared to what we have for example for 1835 and 1880 currently. Stefan On 11/13/2013 06:17 PM, Justin Rebelo wrote: > Wow. That's embarrassing. Sorry for the bogus report. The players in the > game all agreed it was a bug and I just went straight to filing rather > than reporting. Won't do that again. ;) > > > On Wed, Nov 13, 2013 at 9:15 AM, Jerry Anderson <jer...@ya... > <mailto:jer...@ya...>> wrote: > > Not a bug. From the rule book - page 7. > "A player who has passed may bid later, if he gets another turn > before the auction ends." > > *From:* Justin Rebelo <jus...@gm... > <mailto:jus...@gm...>> > *To:* rai...@li... > <mailto:rai...@li...> > *Sent:* Wednesday, November 13, 2013 9:04 AM > *Subject:* [Rails-users] Bug in 18GA private auction > > Forgive me if this is not the correct place for this. I am involved > in a game of 18GA (using Cotton Port variant map). We are four > players and during the initial private auction encountered a very > minor bug that is probably an easy fix for someone with intimate > knowledge of the code. > > There were three pending bids on the OSO private company and after > the preceding company auction was concluded, the first player to > have a bid chose to pass. The next two players raised the bids and > then the first player (who had already passed) was prompted as the > next active player with the option to bid again or pass. The player > should not be able to re-enter the private auction in this case. > Easy to work around for now. > > Thanks! > Justin > > ------------------------------------------------------------------------------ > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access > Free app hosting. Or install the open source package on any LAMP server. > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! > http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-users mailing list > Rai...@li... > <mailto:Rai...@li...> > https://lists.sourceforge.net/lists/listinfo/rails-users > > > > > > ------------------------------------------------------------------------------ > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access > Free app hosting. Or install the open source package on any LAMP server. > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! > http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Rails-users mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-users > ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk _______________________________________________ Rails-users mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-users |
|
From: <Dr....@t-...> - 2013-11-14 09:39:29
|
Hi Andrew, this should have been fixed in a later commit. The problem is there that 1880 uses cities that havent been foreseen in the tiledesigner :). And i made the mistake to import the buggy/handmade Tiledesigner Library into the repository, sorr about that. I'll check that again. Can you remember in which branch the buggy library is ? (I hope its only in the 1.7.12_1880 ?) Kind Regards, Martin Von: Andrew Miller <A.J...@bc...> An: rai...@li... Betreff: [Rails-devel] Error when opening TileDictionary.18t in TileDesigner.exe Datum: Wed, 13 Nov 2013 16:10:29 +0100 When I try to open TileDictionary.18t, Tile Designer gives the following error: "Identifier expected on line 16328" Looking at line 16328, it seems that that the JunType has removed. This has also happened to line 16660 (tiles 8887 and 8888 respectively). These changes appear to have been made in this commit: https://sourceforge.net/p/rails/code/ci/72277ff2256f2c1a456753422879fefbc48ca91e/ [1] Andrew Links: ------ [1] https://sourceforge.net/p/rails/code/ci/72277ff2256f2c1a456753422879fefbc48ca91e/ |
|
From: Andrew M. <A.J...@bc...> - 2013-11-13 15:10:36
|
When I try to open TileDictionary.18t, Tile Designer gives the following error: "Identifier expected on line 16328" Looking at line 16328, it seems that that the JunType has removed. This has also happened to line 16660 (tiles 8887 and 8888 respectively). These changes appear to have been made in this commit: https://sourceforge.net/p/rails/code/ci/72277ff2256f2c1a456753422879fefbc48ca91e/ Andrew |
|
From: Stefan F. <ste...@we...> - 2013-11-07 15:04:03
|
There is a rails_2_develop branch now. Please use this branch to start feature development for Rails 2. Stefan On 11/07/2013 12:20 AM, brett lentz wrote: > Stefan - > > We largely agree on the topic of feature branches. > > Using the central repository to host feature branches is fine and > expected. You can create and delete feature branches as-needed. I don't > expect feature branches to be a "permanent" branch in the remote > repository. But, feature branches aren't a part of the release until > they're merged to a branch that's in the release path. > > I read the doc as having master hold just the released versions of code. > That's more the choice we're discussing. Personally, I don't think our > project is large enough to need the extra step of having a 'develop' > branch in between feature branches and master. On a larger project with > a dedicated QA team or a CI tool that validates commits before merging > to master? Sure, the extra step makes sense. For us? I think it's > unnecessary and we'll be fine merging feature branches to master when > the feature is deemed "ready" for the next release. > > Now, with all that said... I am just making a suggestion based on how I > like to work. I'm fine trying out your proposed work flow, too. > > ---Brett. > > > > ---Brett. > > > On Wed, Nov 6, 2013 at 5:06 PM, Stefan Frey <ste...@we... > <mailto:ste...@we...>> wrote: > > Brett, > no I do not agree and I understand the document differently than you do. > > It is no surprise that both of us find us supported, as it states that > feature branches "CAN be pushed to the central repository for > backup/collaboration." > > I prefer having feature branches not in the private repos only for those > two reasons: Provide backups and allow collaboration on features. > The main disadvantage I see, is that it does not allow rewriting the > history later on as soon as it pushed to the repo. > > However we still differ in where to merge new features into and I find > my position supported in the document: > > "instead of branching off of master, feature branches use develop as > their parent branch. When a feature is complete, it gets merged back > into develop. Features should never interact directly with master." > > That is the reason why we have the rails_2_develop branch. > > I agree that new code has not to be fully workable and tested. However > to be merged into develop it must compile and it should not break > existing unit tests. > > Maybe let us start with some coding and than re-consider the decision > after some experience? > > Stefan > > > On 11/06/2013 10:33 PM, brett lentz wrote: > > Stefan - > > > > Your referenced document agrees with what I'm saying. The key detail > > it's omitting is distinguishing between your local repository and > when > > you push to a remote repository. > > > > So, here's the basic workflow: > > > > 0. Everyone should use private branches for their work. All of your > > commits should go to a private branch. Create new private branches to > > organize your work into logical chunks in whatever way makes > sense to you. > > > > 1. When new code is ready for other developers to see, merge your > > private branch with master and push. > > (Note: the pushed code need not be fully working and tested. > It just > > needs to be a logical chunk of work that is ready for broader > discussion > > and public visibility.) > > > > 2. We declare whatever is in master as "ready to release", so the > > release manager creates a "rails-X.Y" branch and pushes that branch. > > This is the maintenance branch for all X.Y.Z releases. > > > > 3. Tag master or the relevant release branch at the point which > X.Y.Z is > > released. > > > > 4. Bug-fix or maintenance commits are merged from the developer's > > private branch to the maintenance branch and, if needed, to master. > > > > We don't need separate "rails_2_develop" and "rails_2_maintenance" > > branches on the remote repository because the "rails_2_develop" > branch > > should be your local private branch. It exists, but it'll never be > > pushed to the public repository. > > > > On the public repository, just use master and "rails_2_0", then > master > > and "rails_2_1", then master and "rails_3_0". > > > > Does that make sense? > > > > > > > > ---Brett. > > > > > > On Wed, Nov 6, 2013 at 4:04 PM, Stefan Frey <ste...@we... > <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>>> wrote: > > > > Brett and Mike: > > I think I am not too far away, but I simply kept the labels from > > > > > https://www.atlassian.com/git/workflows?_escaped_fragment_=workflow-gitflow#!workflow-gitflow > > > > In the document referred above, master is the one that tracks > releases > > and develop is the one where new features get merged into. > > > > Clearly as long as there are no releases so far, we can use > any of > > those, but to make the distinction clear my intention was to > start > > with rails_2_develop. > > > > I assume we are only talking about labels and nothing really > essential > > which cannot be changed easily, I will keep my initial > proposal and > > create a rails_2_develop branch. > > > > This will be the branch that anyone interested to code for > Rails 2.x > > should use as head for his own feature branches. > > > > Stefan > > > > > > On 11/06/2013 03:16 PM, brett lentz wrote: > > > On Wed, Nov 6, 2013 at 1:08 AM, Stefan Frey > <ste...@we... <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>> > > > <mailto:ste...@we... <mailto:ste...@we...> > <mailto:ste...@we... <mailto:ste...@we...>>>> wrote: > > > > > > In my recent proposal rails_2_master was the > maintenance branch > > > and rails_2_develop was the development branch. > > > > > > But maybe we could avoid master and have > > > > > > > > > Why does master need to be avoided? > > > > > > I know the historical use for master, but when we started > work on > > 2.0, > > > that workflow really should have been changed. At this point, > > there's no > > > major work happening on the 1.x code other than 1880. So, it > > seems like > > > a good time to make a change like this. > > > > > > One very typical workflow is to use master for all new > > development, and > > > use branches for stabilization and/or major features that will > > > eventually be merged into master. > > > > > > rails_2_maintenance > > > rails_2_develop > > > > > > which is clear that those are the two official > branches for > > rails_2. > > > > > > > > > > > > Two branches seems completely unnecessary to me. > > > > > > I will setup the develop branch tonight (European time), > > which is the > > > latest stage of development that compiles without error. > > > > > > And I would like to add two requirements to the two > branches: > > > > > > * The maintenance branch has to build without errors > and all > > tests run > > > successfully (unit tests + rails savegame tests) > > > > > > * The develop branch has to build without errors and > only the > > unit tests > > > have to run successfully (rails savegame tests can > show errors). > > > > > > All other (in-offical and private) develop branches > have no > > > requirements. > > > > > > So if anyone wants to merge into those branches, keep > those > > requirements > > > in mind, they are not automatically enforced ;-) > > > > > > > > > On 11/05/2013 05:12 PM, brett lentz wrote: > > > > My suggestion would be to make 'master' the place > for new > > active > > > > development. Then, have maintenance branches for each > > maintained > > > version. > > > > > > > > Thoughts? > > > > > > > > ---Brett. > > > > > > > > > > > > ---Brett. > > > > > > > > > > > > On Tue, Nov 5, 2013 at 10:57 AM, Michael Alexander > > > > <out...@gm... > <mailto:out...@gm...> <mailto:out...@gm... > <mailto:out...@gm...>> > > <mailto:out...@gm... > <mailto:out...@gm...> <mailto:out...@gm... > <mailto:out...@gm...>>> > > > <mailto:out...@gm... > <mailto:out...@gm...> > > <mailto:out...@gm... > <mailto:out...@gm...>> <mailto:out...@gm... > <mailto:out...@gm...> > > <mailto:out...@gm... > <mailto:out...@gm...>>>>> > > > wrote: > > > > > > > > I'd like to get started pushing 1880 into 2.0 - > which > > branch > > > should > > > > I be working in? > > > > > > > > Mike > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > November Webinars for C, C++, Fortran Developers > > > > Accelerate application performance with scalable > > programming > > > models. > > > > Explore > > > > techniques for threading, error checking, > porting, and > > > tuning. Get > > > > the most > > > > from the latest Intel processors and > coprocessors. See > > > abstracts and > > > > register > > > > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > _______________________________________________ > > > > Rails-devel mailing list > > > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>>> > > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > November Webinars for C, C++, Fortran Developers > > > > Accelerate application performance with scalable > programming > > > models. Explore > > > > techniques for threading, error checking, porting, > and tuning. > > > Get the most > > > > from the latest Intel processors and coprocessors. See > > abstracts > > > and register > > > > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rails-devel mailing list > > > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > November Webinars for C, C++, Fortran Developers > > > Accelerate application performance with scalable > programming > > models. > > > Explore > > > techniques for threading, error checking, porting, and > > tuning. Get > > > the most > > > from the latest Intel processors and coprocessors. See > > abstracts and > > > register > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > November Webinars for C, C++, Fortran Developers > > > Accelerate application performance with scalable programming > > models. Explore > > > techniques for threading, error checking, porting, and tuning. > > Get the most > > > from the latest Intel processors and coprocessors. See > abstracts > > and register > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > > > > > > > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > ------------------------------------------------------------------------------ > > November Webinars for C, C++, Fortran Developers > > Accelerate application performance with scalable programming > models. > > Explore > > techniques for threading, error checking, porting, and > tuning. Get > > the most > > from the latest Intel processors and coprocessors. See > abstracts and > > register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > ------------------------------------------------------------------------------ > > November Webinars for C, C++, Fortran Developers > > Accelerate application performance with scalable programming > models. Explore > > techniques for threading, error checking, porting, and tuning. > Get the most > > from the latest Intel processors and coprocessors. See abstracts > and register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > <mailto:Rai...@li...> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get > the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > <mailto:Rai...@li...> > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: brett l. <bre...@gm...> - 2013-11-06 23:21:13
|
Stefan - We largely agree on the topic of feature branches. Using the central repository to host feature branches is fine and expected. You can create and delete feature branches as-needed. I don't expect feature branches to be a "permanent" branch in the remote repository. But, feature branches aren't a part of the release until they're merged to a branch that's in the release path. I read the doc as having master hold just the released versions of code. That's more the choice we're discussing. Personally, I don't think our project is large enough to need the extra step of having a 'develop' branch in between feature branches and master. On a larger project with a dedicated QA team or a CI tool that validates commits before merging to master? Sure, the extra step makes sense. For us? I think it's unnecessary and we'll be fine merging feature branches to master when the feature is deemed "ready" for the next release. Now, with all that said... I am just making a suggestion based on how I like to work. I'm fine trying out your proposed work flow, too. ---Brett. ---Brett. On Wed, Nov 6, 2013 at 5:06 PM, Stefan Frey <ste...@we...> wrote: > Brett, > no I do not agree and I understand the document differently than you do. > > It is no surprise that both of us find us supported, as it states that > feature branches "CAN be pushed to the central repository for > backup/collaboration." > > I prefer having feature branches not in the private repos only for those > two reasons: Provide backups and allow collaboration on features. > The main disadvantage I see, is that it does not allow rewriting the > history later on as soon as it pushed to the repo. > > However we still differ in where to merge new features into and I find > my position supported in the document: > > "instead of branching off of master, feature branches use develop as > their parent branch. When a feature is complete, it gets merged back > into develop. Features should never interact directly with master." > > That is the reason why we have the rails_2_develop branch. > > I agree that new code has not to be fully workable and tested. However > to be merged into develop it must compile and it should not break > existing unit tests. > > Maybe let us start with some coding and than re-consider the decision > after some experience? > > Stefan > > > On 11/06/2013 10:33 PM, brett lentz wrote: > > Stefan - > > > > Your referenced document agrees with what I'm saying. The key detail > > it's omitting is distinguishing between your local repository and when > > you push to a remote repository. > > > > So, here's the basic workflow: > > > > 0. Everyone should use private branches for their work. All of your > > commits should go to a private branch. Create new private branches to > > organize your work into logical chunks in whatever way makes sense to > you. > > > > 1. When new code is ready for other developers to see, merge your > > private branch with master and push. > > (Note: the pushed code need not be fully working and tested. It just > > needs to be a logical chunk of work that is ready for broader discussion > > and public visibility.) > > > > 2. We declare whatever is in master as "ready to release", so the > > release manager creates a "rails-X.Y" branch and pushes that branch. > > This is the maintenance branch for all X.Y.Z releases. > > > > 3. Tag master or the relevant release branch at the point which X.Y.Z is > > released. > > > > 4. Bug-fix or maintenance commits are merged from the developer's > > private branch to the maintenance branch and, if needed, to master. > > > > We don't need separate "rails_2_develop" and "rails_2_maintenance" > > branches on the remote repository because the "rails_2_develop" branch > > should be your local private branch. It exists, but it'll never be > > pushed to the public repository. > > > > On the public repository, just use master and "rails_2_0", then master > > and "rails_2_1", then master and "rails_3_0". > > > > Does that make sense? > > > > > > > > ---Brett. > > > > > > On Wed, Nov 6, 2013 at 4:04 PM, Stefan Frey <ste...@we... > > <mailto:ste...@we...>> wrote: > > > > Brett and Mike: > > I think I am not too far away, but I simply kept the labels from > > > > > https://www.atlassian.com/git/workflows?_escaped_fragment_=workflow-gitflow#!workflow-gitflow > > > > In the document referred above, master is the one that tracks > releases > > and develop is the one where new features get merged into. > > > > Clearly as long as there are no releases so far, we can use any of > > those, but to make the distinction clear my intention was to start > > with rails_2_develop. > > > > I assume we are only talking about labels and nothing really > essential > > which cannot be changed easily, I will keep my initial proposal and > > create a rails_2_develop branch. > > > > This will be the branch that anyone interested to code for Rails 2.x > > should use as head for his own feature branches. > > > > Stefan > > > > > > On 11/06/2013 03:16 PM, brett lentz wrote: > > > On Wed, Nov 6, 2013 at 1:08 AM, Stefan Frey <ste...@we... > > <mailto:ste...@we...> > > > <mailto:ste...@we... <mailto:ste...@we...>>> wrote: > > > > > > In my recent proposal rails_2_master was the maintenance > branch > > > and rails_2_develop was the development branch. > > > > > > But maybe we could avoid master and have > > > > > > > > > Why does master need to be avoided? > > > > > > I know the historical use for master, but when we started work on > > 2.0, > > > that workflow really should have been changed. At this point, > > there's no > > > major work happening on the 1.x code other than 1880. So, it > > seems like > > > a good time to make a change like this. > > > > > > One very typical workflow is to use master for all new > > development, and > > > use branches for stabilization and/or major features that will > > > eventually be merged into master. > > > > > > rails_2_maintenance > > > rails_2_develop > > > > > > which is clear that those are the two official branches for > > rails_2. > > > > > > > > > > > > Two branches seems completely unnecessary to me. > > > > > > I will setup the develop branch tonight (European time), > > which is the > > > latest stage of development that compiles without error. > > > > > > And I would like to add two requirements to the two branches: > > > > > > * The maintenance branch has to build without errors and all > > tests run > > > successfully (unit tests + rails savegame tests) > > > > > > * The develop branch has to build without errors and only the > > unit tests > > > have to run successfully (rails savegame tests can show > errors). > > > > > > All other (in-offical and private) develop branches have no > > > requirements. > > > > > > So if anyone wants to merge into those branches, keep those > > requirements > > > in mind, they are not automatically enforced ;-) > > > > > > > > > On 11/05/2013 05:12 PM, brett lentz wrote: > > > > My suggestion would be to make 'master' the place for new > > active > > > > development. Then, have maintenance branches for each > > maintained > > > version. > > > > > > > > Thoughts? > > > > > > > > ---Brett. > > > > > > > > > > > > ---Brett. > > > > > > > > > > > > On Tue, Nov 5, 2013 at 10:57 AM, Michael Alexander > > > > <out...@gm... <mailto:out...@gm...> > > <mailto:out...@gm... <mailto:out...@gm...>> > > > <mailto:out...@gm... > > <mailto:out...@gm...> <mailto:out...@gm... > > <mailto:out...@gm...>>>> > > > wrote: > > > > > > > > I'd like to get started pushing 1880 into 2.0 - which > > branch > > > should > > > > I be working in? > > > > > > > > Mike > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > November Webinars for C, C++, Fortran Developers > > > > Accelerate application performance with scalable > > programming > > > models. > > > > Explore > > > > techniques for threading, error checking, porting, and > > > tuning. Get > > > > the most > > > > from the latest Intel processors and coprocessors. See > > > abstracts and > > > > register > > > > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > _______________________________________________ > > > > Rails-devel mailing list > > > > Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>> > > > > <mailto:Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>>> > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > November Webinars for C, C++, Fortran Developers > > > > Accelerate application performance with scalable > programming > > > models. Explore > > > > techniques for threading, error checking, porting, and > tuning. > > > Get the most > > > > from the latest Intel processors and coprocessors. See > > abstracts > > > and register > > > > > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > > > > > > > > > > > > > _______________________________________________ > > > > Rails-devel mailing list > > > > Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>> > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > November Webinars for C, C++, Fortran Developers > > > Accelerate application performance with scalable programming > > models. > > > Explore > > > techniques for threading, error checking, porting, and > > tuning. Get > > > the most > > > from the latest Intel processors and coprocessors. See > > abstracts and > > > register > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > November Webinars for C, C++, Fortran Developers > > > Accelerate application performance with scalable programming > > models. Explore > > > techniques for threading, error checking, porting, and tuning. > > Get the most > > > from the latest Intel processors and coprocessors. See abstracts > > and register > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > > > > > > > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > <mailto:Rai...@li...> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > ------------------------------------------------------------------------------ > > November Webinars for C, C++, Fortran Developers > > Accelerate application performance with scalable programming models. > > Explore > > techniques for threading, error checking, porting, and tuning. Get > > the most > > from the latest Intel processors and coprocessors. See abstracts and > > register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > <mailto:Rai...@li...> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > ------------------------------------------------------------------------------ > > November Webinars for C, C++, Fortran Developers > > Accelerate application performance with scalable programming models. > Explore > > techniques for threading, error checking, porting, and tuning. Get the > most > > from the latest Intel processors and coprocessors. See abstracts and > register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Stefan F. <ste...@we...> - 2013-11-06 22:41:13
|
Brett, no I do not agree and I understand the document differently than you do. It is no surprise that both of us find us supported, as it states that feature branches "CAN be pushed to the central repository for backup/collaboration." I prefer having feature branches not in the private repos only for those two reasons: Provide backups and allow collaboration on features. The main disadvantage I see, is that it does not allow rewriting the history later on as soon as it pushed to the repo. However we still differ in where to merge new features into and I find my position supported in the document: "instead of branching off of master, feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with master." That is the reason why we have the rails_2_develop branch. I agree that new code has not to be fully workable and tested. However to be merged into develop it must compile and it should not break existing unit tests. Maybe let us start with some coding and than re-consider the decision after some experience? Stefan On 11/06/2013 10:33 PM, brett lentz wrote: > Stefan - > > Your referenced document agrees with what I'm saying. The key detail > it's omitting is distinguishing between your local repository and when > you push to a remote repository. > > So, here's the basic workflow: > > 0. Everyone should use private branches for their work. All of your > commits should go to a private branch. Create new private branches to > organize your work into logical chunks in whatever way makes sense to you. > > 1. When new code is ready for other developers to see, merge your > private branch with master and push. > (Note: the pushed code need not be fully working and tested. It just > needs to be a logical chunk of work that is ready for broader discussion > and public visibility.) > > 2. We declare whatever is in master as "ready to release", so the > release manager creates a "rails-X.Y" branch and pushes that branch. > This is the maintenance branch for all X.Y.Z releases. > > 3. Tag master or the relevant release branch at the point which X.Y.Z is > released. > > 4. Bug-fix or maintenance commits are merged from the developer's > private branch to the maintenance branch and, if needed, to master. > > We don't need separate "rails_2_develop" and "rails_2_maintenance" > branches on the remote repository because the "rails_2_develop" branch > should be your local private branch. It exists, but it'll never be > pushed to the public repository. > > On the public repository, just use master and "rails_2_0", then master > and "rails_2_1", then master and "rails_3_0". > > Does that make sense? > > > > ---Brett. > > > On Wed, Nov 6, 2013 at 4:04 PM, Stefan Frey <ste...@we... > <mailto:ste...@we...>> wrote: > > Brett and Mike: > I think I am not too far away, but I simply kept the labels from > > https://www.atlassian.com/git/workflows?_escaped_fragment_=workflow-gitflow#!workflow-gitflow > > In the document referred above, master is the one that tracks releases > and develop is the one where new features get merged into. > > Clearly as long as there are no releases so far, we can use any of > those, but to make the distinction clear my intention was to start > with rails_2_develop. > > I assume we are only talking about labels and nothing really essential > which cannot be changed easily, I will keep my initial proposal and > create a rails_2_develop branch. > > This will be the branch that anyone interested to code for Rails 2.x > should use as head for his own feature branches. > > Stefan > > > On 11/06/2013 03:16 PM, brett lentz wrote: > > On Wed, Nov 6, 2013 at 1:08 AM, Stefan Frey <ste...@we... > <mailto:ste...@we...> > > <mailto:ste...@we... <mailto:ste...@we...>>> wrote: > > > > In my recent proposal rails_2_master was the maintenance branch > > and rails_2_develop was the development branch. > > > > But maybe we could avoid master and have > > > > > > Why does master need to be avoided? > > > > I know the historical use for master, but when we started work on > 2.0, > > that workflow really should have been changed. At this point, > there's no > > major work happening on the 1.x code other than 1880. So, it > seems like > > a good time to make a change like this. > > > > One very typical workflow is to use master for all new > development, and > > use branches for stabilization and/or major features that will > > eventually be merged into master. > > > > rails_2_maintenance > > rails_2_develop > > > > which is clear that those are the two official branches for > rails_2. > > > > > > > > Two branches seems completely unnecessary to me. > > > > I will setup the develop branch tonight (European time), > which is the > > latest stage of development that compiles without error. > > > > And I would like to add two requirements to the two branches: > > > > * The maintenance branch has to build without errors and all > tests run > > successfully (unit tests + rails savegame tests) > > > > * The develop branch has to build without errors and only the > unit tests > > have to run successfully (rails savegame tests can show errors). > > > > All other (in-offical and private) develop branches have no > > requirements. > > > > So if anyone wants to merge into those branches, keep those > requirements > > in mind, they are not automatically enforced ;-) > > > > > > On 11/05/2013 05:12 PM, brett lentz wrote: > > > My suggestion would be to make 'master' the place for new > active > > > development. Then, have maintenance branches for each > maintained > > version. > > > > > > Thoughts? > > > > > > ---Brett. > > > > > > > > > ---Brett. > > > > > > > > > On Tue, Nov 5, 2013 at 10:57 AM, Michael Alexander > > > <out...@gm... <mailto:out...@gm...> > <mailto:out...@gm... <mailto:out...@gm...>> > > <mailto:out...@gm... > <mailto:out...@gm...> <mailto:out...@gm... > <mailto:out...@gm...>>>> > > wrote: > > > > > > I'd like to get started pushing 1880 into 2.0 - which > branch > > should > > > I be working in? > > > > > > Mike > > > > > > > > > ------------------------------------------------------------------------------ > > > November Webinars for C, C++, Fortran Developers > > > Accelerate application performance with scalable > programming > > models. > > > Explore > > > techniques for threading, error checking, porting, and > > tuning. Get > > > the most > > > from the latest Intel processors and coprocessors. See > > abstracts and > > > register > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > <mailto:Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>>> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > November Webinars for C, C++, Fortran Developers > > > Accelerate application performance with scalable programming > > models. Explore > > > techniques for threading, error checking, porting, and tuning. > > Get the most > > > from the latest Intel processors and coprocessors. See > abstracts > > and register > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > > > > > > > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > ------------------------------------------------------------------------------ > > November Webinars for C, C++, Fortran Developers > > Accelerate application performance with scalable programming > models. > > Explore > > techniques for threading, error checking, porting, and > tuning. Get > > the most > > from the latest Intel processors and coprocessors. See > abstracts and > > register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > ------------------------------------------------------------------------------ > > November Webinars for C, C++, Fortran Developers > > Accelerate application performance with scalable programming > models. Explore > > techniques for threading, error checking, porting, and tuning. > Get the most > > from the latest Intel processors and coprocessors. See abstracts > and register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > <mailto:Rai...@li...> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get > the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > <mailto:Rai...@li...> > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: brett l. <bre...@gm...> - 2013-11-06 21:34:15
|
Stefan - Your referenced document agrees with what I'm saying. The key detail it's omitting is distinguishing between your local repository and when you push to a remote repository. So, here's the basic workflow: 0. Everyone should use private branches for their work. All of your commits should go to a private branch. Create new private branches to organize your work into logical chunks in whatever way makes sense to you. 1. When new code is ready for other developers to see, merge your private branch with master and push. (Note: the pushed code need not be fully working and tested. It just needs to be a logical chunk of work that is ready for broader discussion and public visibility.) 2. We declare whatever is in master as "ready to release", so the release manager creates a "rails-X.Y" branch and pushes that branch. This is the maintenance branch for all X.Y.Z releases. 3. Tag master or the relevant release branch at the point which X.Y.Z is released. 4. Bug-fix or maintenance commits are merged from the developer's private branch to the maintenance branch and, if needed, to master. We don't need separate "rails_2_develop" and "rails_2_maintenance" branches on the remote repository because the "rails_2_develop" branch should be your local private branch. It exists, but it'll never be pushed to the public repository. On the public repository, just use master and "rails_2_0", then master and "rails_2_1", then master and "rails_3_0". Does that make sense? ---Brett. On Wed, Nov 6, 2013 at 4:04 PM, Stefan Frey <ste...@we...> wrote: > Brett and Mike: > I think I am not too far away, but I simply kept the labels from > > > https://www.atlassian.com/git/workflows?_escaped_fragment_=workflow-gitflow#!workflow-gitflow > > In the document referred above, master is the one that tracks releases > and develop is the one where new features get merged into. > > Clearly as long as there are no releases so far, we can use any of > those, but to make the distinction clear my intention was to start > with rails_2_develop. > > I assume we are only talking about labels and nothing really essential > which cannot be changed easily, I will keep my initial proposal and > create a rails_2_develop branch. > > This will be the branch that anyone interested to code for Rails 2.x > should use as head for his own feature branches. > > Stefan > > > On 11/06/2013 03:16 PM, brett lentz wrote: > > On Wed, Nov 6, 2013 at 1:08 AM, Stefan Frey <ste...@we... > > <mailto:ste...@we...>> wrote: > > > > In my recent proposal rails_2_master was the maintenance branch > > and rails_2_develop was the development branch. > > > > But maybe we could avoid master and have > > > > > > Why does master need to be avoided? > > > > I know the historical use for master, but when we started work on 2.0, > > that workflow really should have been changed. At this point, there's no > > major work happening on the 1.x code other than 1880. So, it seems like > > a good time to make a change like this. > > > > One very typical workflow is to use master for all new development, and > > use branches for stabilization and/or major features that will > > eventually be merged into master. > > > > rails_2_maintenance > > rails_2_develop > > > > which is clear that those are the two official branches for rails_2. > > > > > > > > Two branches seems completely unnecessary to me. > > > > I will setup the develop branch tonight (European time), which is the > > latest stage of development that compiles without error. > > > > And I would like to add two requirements to the two branches: > > > > * The maintenance branch has to build without errors and all tests > run > > successfully (unit tests + rails savegame tests) > > > > * The develop branch has to build without errors and only the unit > tests > > have to run successfully (rails savegame tests can show errors). > > > > All other (in-offical and private) develop branches have no > > requirements. > > > > So if anyone wants to merge into those branches, keep those > requirements > > in mind, they are not automatically enforced ;-) > > > > > > On 11/05/2013 05:12 PM, brett lentz wrote: > > > My suggestion would be to make 'master' the place for new active > > > development. Then, have maintenance branches for each maintained > > version. > > > > > > Thoughts? > > > > > > ---Brett. > > > > > > > > > ---Brett. > > > > > > > > > On Tue, Nov 5, 2013 at 10:57 AM, Michael Alexander > > > <out...@gm... <mailto:out...@gm...> > > <mailto:out...@gm... <mailto:out...@gm...>>> > > wrote: > > > > > > I'd like to get started pushing 1880 into 2.0 - which branch > > should > > > I be working in? > > > > > > Mike > > > > > > > > > ------------------------------------------------------------------------------ > > > November Webinars for C, C++, Fortran Developers > > > Accelerate application performance with scalable programming > > models. > > > Explore > > > techniques for threading, error checking, porting, and > > tuning. Get > > > the most > > > from the latest Intel processors and coprocessors. See > > abstracts and > > > register > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > <mailto:Rai...@li...> > > > <mailto:Rai...@li... > > <mailto:Rai...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > November Webinars for C, C++, Fortran Developers > > > Accelerate application performance with scalable programming > > models. Explore > > > techniques for threading, error checking, porting, and tuning. > > Get the most > > > from the latest Intel processors and coprocessors. See abstracts > > and register > > > > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > > > > > > > > > _______________________________________________ > > > Rails-devel mailing list > > > Rai...@li... > > <mailto:Rai...@li...> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > ------------------------------------------------------------------------------ > > November Webinars for C, C++, Fortran Developers > > Accelerate application performance with scalable programming models. > > Explore > > techniques for threading, error checking, porting, and tuning. Get > > the most > > from the latest Intel processors and coprocessors. See abstracts and > > register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > <mailto:Rai...@li...> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > ------------------------------------------------------------------------------ > > November Webinars for C, C++, Fortran Developers > > Accelerate application performance with scalable programming models. > Explore > > techniques for threading, error checking, porting, and tuning. Get the > most > > from the latest Intel processors and coprocessors. See abstracts and > register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Stefan F. <ste...@we...> - 2013-11-06 21:04:57
|
Brett and Mike: I think I am not too far away, but I simply kept the labels from https://www.atlassian.com/git/workflows?_escaped_fragment_=workflow-gitflow#!workflow-gitflow In the document referred above, master is the one that tracks releases and develop is the one where new features get merged into. Clearly as long as there are no releases so far, we can use any of those, but to make the distinction clear my intention was to start with rails_2_develop. I assume we are only talking about labels and nothing really essential which cannot be changed easily, I will keep my initial proposal and create a rails_2_develop branch. This will be the branch that anyone interested to code for Rails 2.x should use as head for his own feature branches. Stefan On 11/06/2013 03:16 PM, brett lentz wrote: > On Wed, Nov 6, 2013 at 1:08 AM, Stefan Frey <ste...@we... > <mailto:ste...@we...>> wrote: > > In my recent proposal rails_2_master was the maintenance branch > and rails_2_develop was the development branch. > > But maybe we could avoid master and have > > > Why does master need to be avoided? > > I know the historical use for master, but when we started work on 2.0, > that workflow really should have been changed. At this point, there's no > major work happening on the 1.x code other than 1880. So, it seems like > a good time to make a change like this. > > One very typical workflow is to use master for all new development, and > use branches for stabilization and/or major features that will > eventually be merged into master. > > rails_2_maintenance > rails_2_develop > > which is clear that those are the two official branches for rails_2. > > > > Two branches seems completely unnecessary to me. > > I will setup the develop branch tonight (European time), which is the > latest stage of development that compiles without error. > > And I would like to add two requirements to the two branches: > > * The maintenance branch has to build without errors and all tests run > successfully (unit tests + rails savegame tests) > > * The develop branch has to build without errors and only the unit tests > have to run successfully (rails savegame tests can show errors). > > All other (in-offical and private) develop branches have no > requirements. > > So if anyone wants to merge into those branches, keep those requirements > in mind, they are not automatically enforced ;-) > > > On 11/05/2013 05:12 PM, brett lentz wrote: > > My suggestion would be to make 'master' the place for new active > > development. Then, have maintenance branches for each maintained > version. > > > > Thoughts? > > > > ---Brett. > > > > > > ---Brett. > > > > > > On Tue, Nov 5, 2013 at 10:57 AM, Michael Alexander > > <out...@gm... <mailto:out...@gm...> > <mailto:out...@gm... <mailto:out...@gm...>>> > wrote: > > > > I'd like to get started pushing 1880 into 2.0 - which branch > should > > I be working in? > > > > Mike > > > > > ------------------------------------------------------------------------------ > > November Webinars for C, C++, Fortran Developers > > Accelerate application performance with scalable programming > models. > > Explore > > techniques for threading, error checking, porting, and > tuning. Get > > the most > > from the latest Intel processors and coprocessors. See > abstracts and > > register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > <mailto:Rai...@li...> > > <mailto:Rai...@li... > <mailto:Rai...@li...>> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > ------------------------------------------------------------------------------ > > November Webinars for C, C++, Fortran Developers > > Accelerate application performance with scalable programming > models. Explore > > techniques for threading, error checking, porting, and tuning. > Get the most > > from the latest Intel processors and coprocessors. See abstracts > and register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > <mailto:Rai...@li...> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get > the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > <mailto:Rai...@li...> > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Mike B. <com...@ip...> - 2013-11-06 16:09:39
|
A seperate master provides a stable fallback common to all development. I have never known a professional software / systems development environment not to have one, and not to insist on one as a security measure. You can do all the development that you want, but until a change is proven to achieve the goals it aims to achieve, it doesn't get added to the master. There is simply too much capacity for confusion and cross-purposes with multiple developers under any other situation, IMO. Mike Bourke Campaign Mastery http://www.campaignmastery.com <http://www.campaignmastery.com/> Co-author, Assassin's Amulet <http://www.legaciescampaignsetting.com/> http://www.legaciescampaignsetting.com |
|
From: brett l. <bre...@gm...> - 2013-11-06 14:17:06
|
On Wed, Nov 6, 2013 at 1:08 AM, Stefan Frey <ste...@we...> wrote: > In my recent proposal rails_2_master was the maintenance branch > and rails_2_develop was the development branch. > > But maybe we could avoid master and have > > Why does master need to be avoided? I know the historical use for master, but when we started work on 2.0, that workflow really should have been changed. At this point, there's no major work happening on the 1.x code other than 1880. So, it seems like a good time to make a change like this. One very typical workflow is to use master for all new development, and use branches for stabilization and/or major features that will eventually be merged into master. > rails_2_maintenance > rails_2_develop > > which is clear that those are the two official branches for rails_2. > > Two branches seems completely unnecessary to me. > I will setup the develop branch tonight (European time), which is the > latest stage of development that compiles without error. > > And I would like to add two requirements to the two branches: > > * The maintenance branch has to build without errors and all tests run > successfully (unit tests + rails savegame tests) > > * The develop branch has to build without errors and only the unit tests > have to run successfully (rails savegame tests can show errors). > > All other (in-offical and private) develop branches have no requirements. > > So if anyone wants to merge into those branches, keep those requirements > in mind, they are not automatically enforced ;-) > > > On 11/05/2013 05:12 PM, brett lentz wrote: > > My suggestion would be to make 'master' the place for new active > > development. Then, have maintenance branches for each maintained version. > > > > Thoughts? > > > > ---Brett. > > > > > > ---Brett. > > > > > > On Tue, Nov 5, 2013 at 10:57 AM, Michael Alexander > > <out...@gm... <mailto:out...@gm...>> wrote: > > > > I'd like to get started pushing 1880 into 2.0 - which branch should > > I be working in? > > > > Mike > > > > > ------------------------------------------------------------------------------ > > November Webinars for C, C++, Fortran Developers > > Accelerate application performance with scalable programming models. > > Explore > > techniques for threading, error checking, porting, and tuning. Get > > the most > > from the latest Intel processors and coprocessors. See abstracts and > > register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > <mailto:Rai...@li...> > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > > > > > > ------------------------------------------------------------------------------ > > November Webinars for C, C++, Fortran Developers > > Accelerate application performance with scalable programming models. > Explore > > techniques for threading, error checking, porting, and tuning. Get the > most > > from the latest Intel processors and coprocessors. See abstracts and > register > > > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > > > > > _______________________________________________ > > Rails-devel mailing list > > Rai...@li... > > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Stefan F. <ste...@we...> - 2013-11-06 06:08:48
|
In my recent proposal rails_2_master was the maintenance branch and rails_2_develop was the development branch. But maybe we could avoid master and have rails_2_maintenance rails_2_develop which is clear that those are the two official branches for rails_2. I will setup the develop branch tonight (European time), which is the latest stage of development that compiles without error. And I would like to add two requirements to the two branches: * The maintenance branch has to build without errors and all tests run successfully (unit tests + rails savegame tests) * The develop branch has to build without errors and only the unit tests have to run successfully (rails savegame tests can show errors). All other (in-offical and private) develop branches have no requirements. So if anyone wants to merge into those branches, keep those requirements in mind, they are not automatically enforced ;-) On 11/05/2013 05:12 PM, brett lentz wrote: > My suggestion would be to make 'master' the place for new active > development. Then, have maintenance branches for each maintained version. > > Thoughts? > > ---Brett. > > > ---Brett. > > > On Tue, Nov 5, 2013 at 10:57 AM, Michael Alexander > <out...@gm... <mailto:out...@gm...>> wrote: > > I'd like to get started pushing 1880 into 2.0 - which branch should > I be working in? > > Mike > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get > the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > <mailto:Rai...@li...> > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > > > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: brett l. <bre...@gm...> - 2013-11-05 16:12:47
|
My suggestion would be to make 'master' the place for new active development. Then, have maintenance branches for each maintained version. Thoughts? ---Brett. ---Brett. On Tue, Nov 5, 2013 at 10:57 AM, Michael Alexander <out...@gm...>wrote: > I'd like to get started pushing 1880 into 2.0 - which branch should I be > working in? > > Mike > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
|
From: Michael A. <out...@gm...> - 2013-11-05 15:57:34
|
I'd like to get started pushing 1880 into 2.0 - which branch should I be working in? Mike |
|
From: Stefan F. <ste...@we...> - 2013-11-01 08:59:49
|
<html>
<head>
<style><!--p.MsoNormal, li.MsoNormal, div.MsoNormal {
margin: 0.0cm;
font-size: 12.0pt;
font-family: "Times New Roman" , serif;
}
a:link, span.MsoHyperlink {
color: blue;
text-decoration: underline;
}
a:visited, span.MsoHyperlinkFollowed {
color: purple;
text-decoration: underline;
}
p {
margin-right: 0.0cm;
margin-left: 0.0cm;
font-size: 12.0pt;
font-family: "Times New Roman" , serif;
}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {
margin: 0.0cm;
font-size: 8.0pt;
font-family: Tahoma , sans-serif;
}
span.BallontekstChar {
font-family: Tahoma , sans-serif;
}
span.E-mailStijl21 {
font-family: Calibri , sans-serif;
color: rgb(31,73,125);
}
*.MsoChpDefault {
font-size: 10.0pt;
}
div.WordSection1 {
page: WordSection1;
}
--></style>
</head>
<body link="blue" vlink="purple">Erik: Most likely the easiest thing to do is to restore from backup, if there have been uncommitted changes. <br>
Then commit those changes and push them to the branch you were coding against. <br>
If you accidentally used 1_7_12, no harm was done, as if I remember correctly there was no development work left in master.<br>
Stefan <br>
<br>
<br><br><div class="gmail_quote">Erik Vos <eri...@xs...> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="WordSection1">
<p class="MsoNormal">
<font color="#1f497d" face="Calibri" size="2"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);">Hi Martin,</span></font>
</p>
<p class="MsoNormal">
<font color="#1f497d" face="Calibri" size="2"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);"> </span></font>
</p>
<p class="MsoNormal">
<font color="#1f497d" face="Calibri" size="2"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);">I made the mistake to do a ‘git pull’ without first checking my own status after a long time of inactivity, and now I seem to be in a mess.</span></font>
</p>
<p class="MsoNormal">
<font color="#1f497d" face="Calibri" size="2"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);"> </span></font>
</p>
<p class="MsoNormal">
<font color="#1f497d" face="Calibri" size="2"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);">Gitbash now reports my status as ‘((v1.7.12)|MERGING), so I suppose I was in the v1.7.12 branch. Don’t remember why.</span></font>
</p>
<p class="MsoNormal">
<font color="#1f497d" face="Calibri" size="2"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);">I also seem to have had some uncommitted local changes, including a detail in 18EU/Map.xml, some initial work for 1837 (map etc.), and the new ‘trainMutexID’ Access attribute that I had proposed last year.</span></font>
</p>
<p class="MsoNormal">
<font color="#1f497d" face="Calibri" size="2"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);"> </span></font>
</p>
<p class="MsoNormal">
<font color="#1f497d" face="Calibri" size="2"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);">As it seems I was in the wrong branch, I think there is not much point in attempting to resolve the merge conflict as it is.</span></font>
</p>
<p class="MsoNormal">
<font color="#1f497d" face="Calibri" size="2"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);">All I really want is to undo that misguided ‘git pull’, and to revert to the situation before that, so I can put my house in order first.</span></font>
</p>
<p class="MsoNormal">
<font color="#1f497d" face="Calibri" size="2"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);">But I’m not sure if there is a simple way to get there without having to go into all the details.</span></font>
</p>
<p class="MsoNormal">
<font color="#1f497d" face="Calibri" size="2"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);"> </span></font>
</p>
<p class="MsoNormal">
<font color="#1f497d" face="Calibri" size="2"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);">I should have good file backups, so perhaps I’ll revert the whole 18XX project directory that way, hoping that the full git status is included.</span></font>
</p>
<p class="MsoNormal">
<font color="#1f497d" face="Calibri" size="2"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);"> </span></font>
</p>
<p class="MsoNormal">
<font color="#1f497d" face="Calibri" size="2"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);">Erik.</span></font>
</p>
<p class="MsoNormal">
<font color="#1f497d" face="Calibri" size="2"><span style="font-size: 11.0pt;font-family: Calibri , sans-serif;color: rgb(31,73,125);"> </span></font>
</p>
<div style="border: none;border-left: solid blue 1.5pt;padding: 0.0cm 0.0cm 0.0cm 4.0pt;">
<div>
<div style="border: none;border-top: solid rgb(181,196,223) 1.0pt;padding: 3.0pt 0.0cm 0.0cm 0.0cm;">
<p class="MsoNormal">
<b><font face="Tahoma" size="2"><span style="font-size: 10.0pt;font-family: Tahoma , sans-serif;font-weight: bold;">From:</span></font></b><font face="Tahoma" size="2"><span style="font-size: 10.0pt;font-family: Tahoma , sans-serif;"> Dr....@t-... [mailto:Dr....@t-...]<br/>
<b><span style="font-weight: bold;">Sent:</span></b> Wednesday, October 23, 2013 3:57 PM<br/>
<b><span style="font-weight: bold;">To:</span></b> Erik Vos<br/>
<b><span style="font-weight: bold;">Subject:</span></b> Re: [Rails-devel] 1880 and 1846</span></font>
</p>
</div>
</div>
<p class="MsoNormal">
<font face="Times New Roman" size="3"><span style="font-size: 12.0pt;"> </span></font>
</p>
<div>
<p style="margin: 0.0cm;">
<font color="black" face="Arial" size="3"><span style="font-size: 12.0pt;font-family: Arial , sans-serif;color: black;">What merge conflicts /errors do you have trying to do what exactly ?</span></font><font color="#1f497d" face="Arial"><span style="font-family: Arial , sans-serif;color: rgb(31,73,125);"></span></font>
</p>
</div>
</div>
</div>
</blockquote></div></body>
</html>
|
|
From: Erik V. <eri...@xs...> - 2013-10-31 15:34:38
|
Hi Martin, I made the mistake to do a ‘git pull’ without first checking my own status after a long time of inactivity, and now I seem to be in a mess. Gitbash now reports my status as ‘((v1.7.12)|MERGING), so I suppose I was in the v1.7.12 branch. Don’t remember why. I also seem to have had some uncommitted local changes, including a detail in 18EU/Map.xml, some initial work for 1837 (map etc.), and the new ‘trainMutexID’ Access attribute that I had proposed last year. As it seems I was in the wrong branch, I think there is not much point in attempting to resolve the merge conflict as it is. All I really want is to undo that misguided ‘git pull’, and to revert to the situation before that, so I can put my house in order first. But I’m not sure if there is a simple way to get there without having to go into all the details. I should have good file backups, so perhaps I’ll revert the whole 18XX project directory that way, hoping that the full git status is included. Erik. From: Dr....@t-... [mailto:Dr....@t-...] Sent: Wednesday, October 23, 2013 3:57 PM To: Erik Vos Subject: Re: [Rails-devel] 1880 and 1846 What merge conflicts /errors do you have trying to do what exactly ? |
|
From: Stefan F. <ste...@we...> - 2013-10-31 12:26:36
|
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 > |
|
From: Stefan F. <ste...@we...> - 2013-10-31 12:20:06
|
Martin: this issue is not surprising: It relates to the fact that the attributes of stop are set static at creation time in Rails 1.x. This is changed in Rails 2.0 already (see below). To remind anyone: Station is an object that refers to the station on the tile. As there is only one object per tile type (even if the game includes several copies of the tile), it cannot be used to store tokens. Stop is an object that refers to the station on the mapHex. This allows storing of the tokens. Stops usually (NOT always) survive a tile lay. The attributes of a stop are assigned at the creation of the stop. What you can do is change the attributes from setRelatedStation at the time of tile lay. However to make this undo-proof all attributes have to be state variables, unless the stop is not set to the previous attributes after a call to undo. In Rails2.0 (compare branch route) this is changed already: Stops only store tokens and a reference to the station (dynamic) and mapHex (static, parent of stop), no other variables that can change. The attributes are always determined at run-time, so there is no need for state variables. Thus there will be no issue there. In 1856 downgrades should work in general, as it implies removing the stop. Upgrades could in principle be an issue, however there are only standard trains in 1856, so the difference between towns and cities is not relevant for revenue calculation. Stefan PS: Could we please keep discussing development issues on the development list? This makes it easier to search for relevant discussions later. Thanks! On 10/29/2013 10:34 PM, Martin Brumm wrote: > Hi Stefan, Michael, Erik, > > upon the placement of a tile with a town onto the new tiles (in 1880) > "Medium" Cities rails so far didnt change the initial type (as we didnt > introduce this special type in the codebase). So its an 1880 problem. > > The quick fix was to alter setRelatedStation in Stop.java to change the > Type and ScoreType to a town also. > > The more complex way might be to alter MapHex and Stop to incorporate > the medium city type. But since that "downgrade" to town is the only > option beside from that station staying as a city tile.... > > But as usual the fix is only in the 1880 release branch yet, we might > however fix that in a different way in 2.0 ? > > On another thought, isnt there another game where you can alter a town > hex to a non town tile ? > > Kind Regards, > Martin > > > |
|
From: Stefan F. <ste...@we...> - 2013-10-29 11:52:06
|
Martin, if you give me a list of the open issues for revenue calculation in 1880 and send me save files for those occasions, I will fix those. However I thought Michael already addressed 1880 specifics of revenue calculation? And please tell me which of the branches is used for latest developments of 1880, for me to start with. Stefan On 10/28/2013 08:58 PM, Martin Brumm wrote: > Hi Antero, > > your last point most likely will be the explanation. But i'll check. The > rails revenue calculation code has not really been updated for 1880. Its > a complex piece of code. So we most likely will have to wait for its > creator to adapt that. Until that happens, player will have to check the > calculation themselves and take the revenue displayed as a guidance only. > > Regards > Martin > > On 28.10.2013 20:42, Antero Kuusi wrote: >> Actually, looking at the move file, the error seems to be something else >> and not of wrong train being used. Foreign Investor 6 had ran correctly >> before that move and it does say that Foreign Investor 7 has a 2+2 train to >> use. However, it still doesn't count the small station to the north of the >> starting location by default. Perhaps some trouble with ending the run in a >> small station and/or the fact that the hex had a medium station originally? >> >> >> 2013/10/28 Antero Kuusi <ak...@ik...> >> >>> Here's a save file examples of the situation just before (Ville) and just >>> after (Atte) the move. >>> >>> Antero >>> >>> >>> 2013/10/28 Martin Brumm <dr....@t-...> >>> >>>> Am 28.10.2013 14:37, schrieb Antero Kuusi: >>>>> We noticed that the train selection for foreign investors does not >>>>> work correctly in all of the situations. Specifically, when the last >>>>> 2T has been bought, but the first 2+2T has not yet been bought, Rails >>>>> uses 2Ts for the foreign investors. >>>>> >>>>> The correct thing would be to use next available train, ie. 2+2T in >>>>> that situation, but without causing a phase change. >>>>> >>>>> We have not tested with the other type changes, but I assume it is the >>>>> same. >>>>> >>>> >>>> HI Antero, >>>> do you guys have a save file available that you could send to me ? >>>> >>>> >>>> >>> >> > > > |
|
From: Martin B. <dr....@t-...> - 2013-10-28 19:59:23
|
Hi Antero, your last point most likely will be the explanation. But i'll check. The rails revenue calculation code has not really been updated for 1880. Its a complex piece of code. So we most likely will have to wait for its creator to adapt that. Until that happens, player will have to check the calculation themselves and take the revenue displayed as a guidance only. Regards Martin On 28.10.2013 20:42, Antero Kuusi wrote: > Actually, looking at the move file, the error seems to be something else > and not of wrong train being used. Foreign Investor 6 had ran correctly > before that move and it does say that Foreign Investor 7 has a 2+2 train to > use. However, it still doesn't count the small station to the north of the > starting location by default. Perhaps some trouble with ending the run in a > small station and/or the fact that the hex had a medium station originally? > > > 2013/10/28 Antero Kuusi <ak...@ik...> > >> Here's a save file examples of the situation just before (Ville) and just >> after (Atte) the move. >> >> Antero >> >> >> 2013/10/28 Martin Brumm <dr....@t-...> >> >>> Am 28.10.2013 14:37, schrieb Antero Kuusi: >>>> We noticed that the train selection for foreign investors does not >>>> work correctly in all of the situations. Specifically, when the last >>>> 2T has been bought, but the first 2+2T has not yet been bought, Rails >>>> uses 2Ts for the foreign investors. >>>> >>>> The correct thing would be to use next available train, ie. 2+2T in >>>> that situation, but without causing a phase change. >>>> >>>> We have not tested with the other type changes, but I assume it is the >>>> same. >>>> >>> >>> HI Antero, >>> do you guys have a save file available that you could send to me ? >>> >>> >>> >> > |
|
From: Martin B. <dr....@t-...> - 2013-10-26 21:36:20
|
From a different source came a bugreport. I would like to share this here, and of course the current state of work. The test had been done with 1.8.0. >steveyu wrote: >I've been testing the latest build to see if we could progress further and ran into the following that I emailed to >Martin. I don't mind redoing the save file, but as some of these seem to still be game breaking, I am going to hold >off for a bit. >listed below in order of importance: >1. Communism did not end on the purchase of the first 6 train. Stock values and bonuses remained locked until the >end of the game. >2. The game did not actually have a game ending triggering event, - the 8s were purchased and then the game >continued running round after round until it crashed. >3. The 6s did not trigger the purchase of the reconstructed 2s. The train order went - 6, 6E, 8, 8E, 2R, 10. >4. The 8Es were not purchasable. When the last 8 exported, the 8Es were also all exported and the 2Rs were then >allowed to be purchased. >5. Companies did not recapitalize if the 3s were all exported rather than purchased triggering the recap. We worked >around this by adding money to a company and then moving a 3 around until the 6s rusted it. >6. Related to this - it seems when any trains are all exported, it does not trigger the related event (such as start of >communism or recapitalization). >7. 6Es do not get calculated and do not seem to run at all -manually did the route calculation (I assume 8Es are the >same way but we could not buy any). >8. The double dit tile 8855 only calculates the town on one of the two dits. The other direction is treated as a >straight tile with no town on it. >9. The D permit private company could not be used to assign the D permit to any major companies. >10. Ferries do not seem to deduct $10 from any routes that used the ferry. Item 1 Fixed in 1.8.2 Item 3 fixed in 1.8.2 Item 5 fixed in 1.8.2 Item 2,4, 6 not yet verified, still under inspection. Items 8-9 still in investigation as no save file avail 7 will be fixed in 1.8.3 4 will be fixed in 1.8.3 6 is fixed in 1.8.2 10 fixed in 1.8.2 Roadmap for 1.8.3: Fixing the remaining problems with Double-O-Tiles Fixing the remaining problems with 2R train special treatment The Revenuecalculation for the 6E and 8E will be working but should be handled manually, the code now has no chance (at least as far as i understood that specific part) to maximise the Revenue yet. Regards, Martin |
|
From: jralpar <jr...@gm...> - 2013-10-23 17:51:42
|
Hi I would like to inform the list of an error I have found during play of the 1880 module. In a five player game, using the "rewind" button in the report window, one can create a situation where both 2+2 and 3 trains are available from the IPO. Both the 2+2s and the 3s become available in the drop down and are listed in the "New" box in the game status. See attached screen and save file. Thanks. |
|
From: brett l. <bre...@gm...> - 2013-10-23 14:13:40
|
+1. Works for me. :) ---Brett. On Wed, Oct 23, 2013 at 2:06 AM, Stefan Frey <ste...@we...> wrote: > Hi all, > as there was some discussion and confusion on how release management > should work I have created the proposal below for Rails release > management for Rails 2.x. I tried to keep it as simple as possible. > > I propose myself as a release manager for Rails 2.x. This implies > that the only one which eventually merges new features and bug-fixes > into the official branches will be me. > > However if you look carefully into the proposal this will require no > active intervention as I require that the new code is rebased on the > branch it will be merged into. Thus there will never be any merge > conflicts, it is merely a kind of giving the "final go". > > This is not a bad thing because after the "final go", all other > developers have to rebase on the new feature changes before they can get > their stuff in. So the "final go" will always be the chance to identify > and discuss potential future merge conflicts. > > I will write something about Rails 1.x release management later today. > > Stefan > > > Proposal for Rails 2.x Release Management: > > Rails release management for Rails 2.x will follow the "Gitflow" Workflow: > > https://www.atlassian.com/git/workflows#!workflow-gitflow > > There will be two official branches: > > ** Name conventions: > - Official branches will be called "rails_#_". > - Branches for new features can use any name, except those starting with > "rails_". > - Branches for bug fixes start with "fix_". > > ** Official Rails 2 branches > - rails_2_master > - rails_2_develop > > ** Working on bug fixes: > Create a branch from master, fix the bug, run tests, commit and push. > Finished: Ask to be merged into master by release manager. > > ** Working on new features: > Create a branch from develop. > Iterate on: Code, rebase on develop, run tests, commit and push. > Finished: Ask to be merged into develop by release manager. > > ** Optional (later): Release branch > If there is the need, develop will be separated into the long-running > develop branch and a short-running release branch. > > ** Further Remarks: > - Whitespace issues should be taken care by the .gitattributes file > settings in the repo. > - I will only merge features that are rebased against the current > develop branch (so usually "git rebase rails_2_develop") > - You can set git to use rebase for new branches on pull with "git > config --global branch.autosetuprebase always", or use "git pull --rebase" > > > ------------------------------------------------------------------------------ > 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=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Stefan F. <ste...@we...> - 2013-10-23 11:08:29
|
Mike, thanks for reminding me that I forgot to highlight this: * If all developers follow this strategy the release manager does in fact NOTHING, except than a final fast-forward from the feature branch to the develop branch. No code will be changed. This task ould be done by any other developer who can write to the repo. * If any developer choose not to follow the strategy, the release manager has NO power to prevent him from doing so. There is no special connection or dependency to my person. It is more a service that I try to offer to ensure that all tests have been run, that nothing gets merged silently to develop etc. I will have no rights how things get implemented and I have no intention to claim them, except by the power of argument. If a developer feels that I take to long to merge things, he is still free to merge as soon as he prefers. There are no additional rights on the repo associated on the repo with that. Git allows any approach of releases, branching or forking strategy, so any developer is free to choose his own approach. However freedom comes with the price of potential chaos. I suggest some discipline in the beginning of Rails 2.x to avoid what happened in Rails 1.x: It is not pretty bad, but I could be better. And for this I have to blame myself as I did not provide a clear proposal that others were able to follow easily. Stefan On 10/23/2013 11:06 AM, Mike Bourke wrote: > The only thing that I can see wrong with this proposal is the question of > what happens if you get hit by a bus or something, Stefan. Not that I wish > you any ill, but some sort of contingancy should be built into the plan :) > > Mike Bourke > Campaign Mastery http://www.campaignmastery.com > Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com > > > ------------------------------------------------------------------------------ > 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=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
99 messages has been excluded from this view by a project administrator.
