> 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? >
Once 0.12.(z-1) is published (i.e., from 0.12.(z-1)-rc4) it's immutable for all time. That is, 0.12.z should be based on 0.12.(z-1) so it too will include the bad commit message. Both 0.12.z-rc1 and 0.12.z-rc2 should share the same 0.12.(z-1) parent but could have different commits. And then 0.12.(z+1) will be based on which ever 0.12.z release candidate is picked (and now called just 0.12.z). > > > 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? >>>> >>>> >>> >> >
