Hi, With the recent switch to git and the debate on branching for 6.x going on, may I suggest taking a look at the git workflow of the apache Cassandra project? http://wiki.apache.org/cassandra/HowToContribute#Committing (There's a link to a Google TechTalk video with an in-depth explanation too)
They currently have 4 (4!) supported releases, each in their own branch, and still keep everything manageable. Basically, they apply changes at the lowest release for which the change is applicable and then merge the change upwards to the other releases and eventually to trunk. IMHO it has the following advantages: - A fix for an issue (even if it would be a long-running side-branch) occurs only once in the full project log. - No more cherry-picking - Instead of having parallel logs per version, it's immediately clear which fixes are applied to which version - No fixes for a lower version can be forgotten in a higher version (the committer of the next fix would notice) - Back-porting is still possible if really necessary by cherry-picking. The merge-upward would be a no-op, but still make clear the versions are in sync. - If you have a graphical tool to visualize the log (even if only using ascii art), it looks beautiful :) If you want to take a look, their git repository is at: http://git-wip-us.apache.org/repos/asf/cassandra.git Luc -----Original Message----- From: Shalin Shekhar Mangar [mailto:shalinman...@gmail.com] Sent: donderdag 3 maart 2016 17:30 To: dev@lucene.apache.org Subject: [Possibly spoofed] Re: Lucene/Solr 6.0.0 Release Branch Mike, I'll fix the TestBackwardsCompatibility. The mistake was to freeze the 6x branch in the first place. The release branch is the one which should be frozen. I specifically asked the RM to cut the branch to let others progress but I received no replies -- which is why I was forced to do it myself. In future, the RM should keep this in mind and not block others. The rest of the problem was because I am new to Git -- in subversion a release branch is always copied from the server so pulling latest changes locally before creating the branch did not cross my mind. On Thu, Mar 3, 2016 at 9:46 PM, Michael McCandless <luc...@mikemccandless.com> wrote: > Shalin, > > In the future please don't jump the gun like this? > > It has caused a lot of unnecessary chaos. It should be the RM, and > only the RM, that is doing things like creating release branches, > bumping versions, etc., at release time. > > Also, your changes to bump the version on 6.x seem to be causing > TestBackwardsCompatibility to be failing. Can you please fix that? > In the future, when you are RM, please run tests when bumping versions > before pushing. > > A major release is hard enough with only one chef. > > Mike McCandless > > http://blog.mikemccandless.com > > > On Thu, Mar 3, 2016 at 8:52 AM, Shalin Shekhar Mangar > <shalinman...@gmail.com> wrote: >> Hmm I think I created the branch without pulling the latest code. I'll fix. >> >> On Thu, Mar 3, 2016 at 6:41 PM, Robert Muir <rcm...@gmail.com> wrote: >>> This is missing a bunch of yesterday's branch_6x changes. Some of >>> david smiley's spatial work, at least one of my commits. >>> >>> On Thu, Mar 3, 2016 at 5:10 AM, Shalin Shekhar Mangar >>> <shalinman...@gmail.com> wrote: >>>> FYI, I have created the branch_6_0 so that we can continue to commit >>>> stuff intended for 6.1 on master and branch_6x. I have also added the >>>> 6.1.0 version on branch_6x and master. >>>> >>>> On Wed, Mar 2, 2016 at 9:51 PM, Shawn Heisey <apa...@elyograg.org> wrote: >>>>> On 3/2/2016 4:19 AM, Alan Woodward wrote: >>>>>> Should we create a separate branch_6_0 branch for the feature-freeze? >>>>>> I have stuff to push into master and that should eventually make it >>>>>> into 6.1, and it will be easy to forget to backport stuff if there's a >>>>>> week before I can do that… >>>>> >>>>> +1 >>>>> >>>>> When I saw Nick's email about branch_6x being feature frozen, my first >>>>> thought was that we don't (and really can't) feature freeze the stable >>>>> branch -- isn't new feature development (for the next minor release in >>>>> the current major version) the entire purpose of branch_Nx? >>>>> >>>>> A feature freeze on a specific minor version does make sense. I've seen >>>>> a couple of people say that we have, but there are also a few messages >>>>> from people saying that they want to include new functionality in 6.0. >>>>> I expect that backporting almost anything from branch_6x to branch_6_0 >>>>> will be relatively easy, so it may be a good idea to just create the new >>>>> branch. >>>>> >>>>> Thanks, >>>>> Shawn >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>>> >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Shalin Shekhar Mangar. >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >> >> >> -- >> Regards, >> Shalin Shekhar Mangar. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > -- Regards, Shalin Shekhar Mangar. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
