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