mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Mahler <benjamin.mah...@gmail.com>
Subject Re: [DISCUSS] Release process
Date Wed, 05 Jun 2013 20:51:44 GMT
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 <vinodkone@gmail.com> 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 <vinodkone@gmail.com> 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 <benh@berkeley.edu>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) <
>>>> chris.a.mattmann@jpl.nasa.gov> 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: chris.a.mattmann@nasa.gov
>>>>> 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 <benjamin.mahler@gmail.com>
>>>>> Reply-To: "mesos-dev@incubator.apache.org" <
>>>>> mesos-dev@incubator.apache.org>
>>>>> Date: Tuesday, June 4, 2013 7:23 PM
>>>>> To: Benjamin Hindman <benh@berkeley.edu>, Vinod Kone <
>>>>> vinodkone@gmail.com>
>>>>> Cc: "mesos-dev@incubator.apache.org" <mesos-dev@incubator.apache.org>
>>>>> 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 general@incubator.apache.org and
>>>>> >mesos-dev@incubator.apache.orgcalling 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?
>>>>>
>>>>>
>>>>
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message