Looking at cassandra, their last branch is cassandra-1.1.0 whereas they have tags since then for all of their new releases: https://github.com/apache/cassandra/tags
So it appears they made the same switch. On Wed, Jun 5, 2013 at 1:38 PM, Vinod Kone <[email protected]> wrote: > Also, a few Apache projects I sampled on GitHub all seem to use the 0.12.x > branch strategy. So, I would like to understand how those guys are able to > get around the issues we are facing. > > https://github.com/apache/httpd/branches > https://github.com/apache/thrift/branches > https://github.com/apache/hbase/branches > https://github.com/apache/cassandra/branches > > > > On Wed, Jun 5, 2013 at 1:34 PM, Vinod Kone <[email protected]> wrote: > >> SGTM. Though, I have one question? >> >> What if there is a bad commit message in 0.12.(z-1)-rcN that you want to >> amend in 0.12.z-rc1 ? Would we not allow this? Is the requirement going to >> be that a non-fast-forward 0.12.(z-1)-rc(N+1) be released first and then >> base 0.12.z-rc1 be based off that? >> >> >> On Wed, Jun 5, 2013 at 1:22 PM, Benjamin Hindman <[email protected]>wrote: >> >>> Thanks for capturing the discussion Ben. A few thoughts inline. >>> >>> The process would be as follows: >>>> >>>> 1. Tag a candidate: 0.12.0-rc1. >>>> 2. Call a VOTE to release RC1. >>>> 3. If successful, release and tag 0.12.0 from 0.12.0-rc1. >>>> 4. Otherwise, progress with 0.12.0-rc2 by creating a local branch off >>>> of 0.12.0-rc1 and applying the necessary commits. >>>> >>> >>> I don't think that 0.12.0-rc2 needs to be branched off of 0.12.0-rc1. >>> For example, we might want to fix a commit message from 0.12.0-rc1 for >>> 0.12.0-rc2 which means that 0.12.0-rc2 will be divergent from 0.12.0-rc1. >>> We should always make 0.12.z-rcN be branched off of 0.12.(z-1), but not >>> have that requirement for candidates (they are just a "candidate" after >>> all). >>> >>> Other than that, this all SGTM! >>> >>> >>> >>> >>>> >>>> History can be seen using 'git log 0.12.0-rc1..0.12.0-rc2'. >>>> >>>> This means tags are immutable, and a source of truth for the RCs and >>>> releases. >>>> >>>> For now, I will be punting on removing the 0.12.x branch, and will >>>> simply create a 0.12.0-rc1 tag to call a VOTE with. But I'd like to gather >>>> thoughts, +1's or -1's. >>>> >>>> There's no documentation that I know of. So, yes documenting the >>>>> checklist is a great idea. >>>>> Also note, that we create branches of the form "0.12.x" instead of >>>>> "0.12.0". This makes it easy to cherry pick commits for future bug fix >>>>> releases and release candidates. >>>>> Also, you might want to checkout the release.sh script (if there are >>>>> some updates to it) from the master branch into 0.12.x. >>>> >>>> >>>> >>>> On Tue, Jun 4, 2013 at 7:50 PM, Mattmann, Chris A (398J) < >>>> [email protected]> wrote: >>>> >>>>> Looking good, Ben M! >>>>> >>>>> Thanks for throwing this up! I've prefixed the subject line >>>>> with a [DISCUSS] thread. Not a requirement by any means but >>>>> makes it nice when looking in mail-archives.apache.org and >>>>> other threaded browsers to see like minded discussion threads :) >>>>> >>>>> So, putting this up on a wiki would be great. >>>>> Looking at: >>>>> >>>>> http://incubator.apache.org/projects/mesos.html >>>>> >>>>> >>>>> We have a confluence wiki here: >>>>> >>>>> https://cwiki.apache.org/confluence/display/MESOS/Index >>>>> >>>>> >>>>> I don't have karma to edit it (need to remove the docs exist >>>>> at Github part). I'm working with infra to get karma. Once I >>>>> get it we should add a release process page there that simply >>>>> copies the below :) >>>>> >>>>> Either way +1 to proceed with step #1. >>>>> >>>>> Cheers, >>>>> Chris >>>>> >>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>> Chris Mattmann, Ph.D. >>>>> Senior Computer Scientist >>>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA >>>>> Office: 171-266B, Mailstop: 171-246 >>>>> Email: [email protected] >>>>> WWW: http://sunset.usc.edu/~mattmann/ >>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>> Adjunct Assistant Professor, Computer Science Department >>>>> University of Southern California, Los Angeles, CA 90089 USA >>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Benjamin Mahler <[email protected]> >>>>> Reply-To: "[email protected]" < >>>>> [email protected]> >>>>> Date: Tuesday, June 4, 2013 7:23 PM >>>>> To: Benjamin Hindman <[email protected]>, Vinod Kone < >>>>> [email protected]> >>>>> Cc: "[email protected]" <[email protected]> >>>>> Subject: Release process. >>>>> >>>>> >Now that 0.11.0 is out, we should continue freeing up the backlog and >>>>> >proceed with 0.12.0. I'll be taking care of this release and I'd like >>>>> to >>>>> >document the release process to make it easier for others to help out >>>>> with >>>>> >releases in the future. Is there already documentation somewhere? >>>>> Here's >>>>> >what I've inferred: >>>>> > >>>>> >1. First I'll gather the JIRA tickets for the CHANGELOG. >>>>> > >>>>> >2. Send out a review / commit the CHANGELOG updates. >>>>> > >>>>> >3. Cherry pick the CHANGELOG onto 0.12.0. >>>>> > >>>>> >4. Run 'git checkout 0.12.0 && ./support/release.sh 0.12.0 1'. >>>>> > >>>>> >5. Mail [email protected] and >>>>> >[email protected] a VOTE. >>>>> > >>>>> >6. After a successful VOTE, add it to the website(s)? >>>>> > >>>>> >7. Upload the jar to artifactory, I see Vinod is having issues with >>>>> that >>>>> >at >>>>> >the moment. >>>>> > >>>>> >Missing anything? >>>>> >>>>> >>>> >>> >> >
