The caveat here is that all of these projects came from, or still use, svn as the canonical repo. Right?
On Wed, Jun 5, 2013 at 2:02 PM, Vinod Kone <[email protected]> wrote: > Well, actually it looks like they merge their (Major.Minor) branches > (Click view merged branches at > https://github.com/apache/cassandra/branches) into trunk, which is also > interesting. > > > > > On Wed, Jun 5, 2013 at 1:51 PM, Benjamin Mahler <[email protected] > > wrote: > >> 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? >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
