From dev-return-50276-archive-asf-public=cust-asf.ponee.io@mesos.apache.org Mon Mar 26 17:30:59 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id F099F180649 for ; Mon, 26 Mar 2018 17:30:58 +0200 (CEST) Received: (qmail 28849 invoked by uid 500); 26 Mar 2018 15:30:57 -0000 Mailing-List: contact dev-help@mesos.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@mesos.apache.org Delivered-To: mailing list dev@mesos.apache.org Received: (qmail 28410 invoked by uid 99); 26 Mar 2018 15:30:57 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Mar 2018 15:30:56 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 636C31A09A8 for ; Mon, 26 Mar 2018 15:30:56 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.529 X-Spam-Level: * X-Spam-Status: No, score=1.529 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=mesosphere-com.20150623.gappssmtp.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 8P8BdhGoRQkP for ; Mon, 26 Mar 2018 15:30:49 +0000 (UTC) Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id BD151629C5 for ; Mon, 26 Mar 2018 13:49:37 +0000 (UTC) Received: by mail-wm0-f70.google.com with SMTP id i19so2261970wmf.1 for ; Mon, 26 Mar 2018 06:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mesosphere-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q+xHAxeMxWK/mJuYJN0ERX/jNf6BmWZyWtK94CVuzFs=; b=XVrt1t7DTAIkVwLISDD3k8Ce6Sy2pNM5NsfCo081GC6k0kM8SpENKQnVee2vEymgA6 ZaGS1+Qw3eCpgwqmVbNqTpJl2eWbgLZPAAx1/gZMZD0xrUsfoEgbpdjOZPKVKlnYih4r 4+f8OGDz6pDlNg2dqpHun412V0jMz4QQShDuZu+s+Bh9cR662KLg3SFDlb4Lo+3NhKNK GYHANhVaCjQ7jopdlOYfPan5AZ+pyBr401lo1etdaJwhYgBj2fAF7lDzdVW0kG3VnIwr 3iYQsnV3zexRY2DrVqF6zOUiXfxeu0uf7cHT+sbTKwFdy0Hlk/F6BBeDjePg6wD9tnJY s/Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q+xHAxeMxWK/mJuYJN0ERX/jNf6BmWZyWtK94CVuzFs=; b=f6LS5OLUdcMrvVhYRTO0A2a2i1ovgHXZSiLiBd7T2D59UUySvp+hPmlMS2pvEHwYtN cVNm0y+MgQYuJO3P6Ayh5mWisQDx/+qjat+0RY5uidZ1MR7C8T4LHIcqd5se6uHo1bRA +4JBgrcQ8r0Sykgt0VJlBcLu+cPw3+CBiQE2eca2abBrN7Aj9/ZQJX0UEoSHdHKnMWNO tHaO4D3qF0pzNXCv5+1Byj646xEDfOvjuuP++YCFR+kPn3FkA7Hkw/4PXesot2iZkt60 P4QqmkaktElwHEHzfdmWEe9e9OHufZ/vRsT8TUcfIcZEk90zCTuQWWhUcnwB4bWw1F8+ nm0w== X-Gm-Message-State: AElRT7FqBQyS0trphIiQ9BHJmJiXgPjhhzfl4ZLAuza8cPE5VVS44fnf n1j0zk6PdumgTinNx8U7fvgz9PXXpwP82BAKrVTygA== X-Google-Smtp-Source: AIpwx48XntrYDjszgnNQpvseApxNKuKcXiM1CFeurACbZ2uQqX05VOFdz8il1z5iopDvJYrKJKaoLcIlnJMPg4lrhdE= X-Received: by 10.28.110.17 with SMTP id j17mr10593152wmc.65.1522072170685; Mon, 26 Mar 2018 06:49:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.184.22 with HTTP; Mon, 26 Mar 2018 06:49:30 -0700 (PDT) In-Reply-To: References: From: Alex Rukletsov Date: Mon, 26 Mar 2018 15:49:30 +0200 Message-ID: Subject: Re: Release policy and 1.6 release schedule To: user Cc: dev Content-Type: multipart/alternative; boundary="089e082fa6d00e7be00568510b5f" --089e082fa6d00e7be00568510b5f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would like us to do monthly releases and support 10 branches at a time. Ideally, releasing that often reduces the burden for the release manager, because there are less changes and less new features. However, we lack automation to support this pace: our release guide [1] is several pages long and includes quite a few non-trivial steps. It would be great to find some time (maybe during the next Mesos hackathon?) and revisit our release procedures, but until then I'm +1 for quarterly. [1] https://mesos.apache.org/documentation/latest/release-guide/ On Sat, Mar 24, 2018 at 5:48 AM, Vinod Kone wrote: > I=E2=80=99m +1 for quarterly. > > Most importantly I want us to adhere to a predictable cadence. > > Sent from my phone > > On Mar 23, 2018, at 9:21 PM, Jie Yu wrote: > > It's a burden for supporting multiple releases. > > 1.2 was released March, 2017 (1 year ago), and I know that some users are > still on that version > 1.3 was released June, 2017 (9 months ago), and we're still maintaining i= t > (still backport patches > several > days ago, which some users asked) > 1.4 was released Sept, 2017 (6 months ago). > 1.5 was released Feb, 2018 (1 month ago). > > As you can see, users expect a release to be supported 6-9 months (e.g., > backports are still needed for 1.3 release, which is 9 months old). If we > were to do monthly minor release, we'll probably need to maintain 6-9 > release branches? That's too much of an ask for committers and maintainer= s. > > I also agree with folks that there're benefits doing releases more > frequently. Given the historical data, I'd suggest we do quarterly > releases, and maintain three release branches. > > - Jie > > On Fri, Mar 23, 2018 at 10:03 AM, Greg Mann wrote: > >> The best motivation I can think of for a shorter release cycle is this: = if >> the release cadence is fast enough, then developers will be less likely = to >> rush a feature into a release. I think this would be a real benefit, sin= ce >> rushing features in hurts stability. *However*, I'm not sure if every tw= o >> months is fast enough to bring this benefit. I would imagine that a >> two-month wait is still long enough that people wouldn't want to wait an >> entire release cycle to land their feature. Just off the top of my head,= I >> might guess that a release cadence of 1 month or shorter would be often >> enough that it would always seem reasonable for a developer to wait unti= l >> the next release to land a feature. What do y'all think? >> >> Other motivating factors that have been raised are: >> 1) Many users upgrade on a longer timescale than every ~2 months. I thin= k >> that this doesn't need to affect our decision regarding release timing - >> since we guarantee compatibility of all releases with the same major >> version number, there is no reason that a user needs to upgrade minor >> releases one at a time. It's fine to go from 1.N to 1.(N+3), for example= . >> 2) Backporting will be a burden if releases are too short. I think that = in >> practice, backporting will not take too much longer. If there was a >> conflict back in the tree somewhere, then it's likely that after resolvi= ng >> that conflict once, the same diff can be used to backport the change to >> previous releases as well. >> 3) Adhering strictly to a time-based release schedule will help users pl= an >> their deployments, since they'll be able to rely on features being >> released >> on-schedule. However, if we do strict time-based releases, then it will = be >> less certain that a particular feature will land in a particular release= , >> and users may have to wait a release cycle to get the feature. >> >> Personally, I find the idea of preventing features from being rushed int= o >> a >> release very compelling. From that perspective, I would love to see >> releases every month. However, if we're not going to release that often, >> then I think it does make sense to adjust our release schedule to >> accommodate the features that community members want to land in a >> particular release. >> >> >> Jie, I'm curious why you suggest a *minimal* interval between releases. >> Could you elaborate a bit on your motivations there? >> >> Cheers, >> Greg >> >> >> On Fri, Mar 16, 2018 at 2:01 PM, Jie Yu wrote: >> >> > Thanks Greg for starting this thread! >> > >> > >> >> My primary motivation here is to bring our documented policy in line >> >> with our practice, whatever that may be >> > >> > >> > +100 >> > >> > Do people think that we should attempt to bring our release cadence mo= re >> >> in line with our current stated policy, or should the policy be chang= ed >> >> to reflect our current practice? >> > >> > >> > I think a minor release every 2 months is probably too aggressive. I >> don't >> > have concrete data, but my feeling is that the frequency that folks >> upgrade >> > Mesos is low. I know that many users are still on 1.2.x. >> > >> > I'd actually suggest that we have a *minimal* interval between two >> > releases (e.g., 3 months), and provide some buffer for the release >> process. >> > (so we're expecting about 3 releases per year, this matches what we di= d >> > last year). >> > >> > And we use our dev sync to coordinate on a release after the minimal >> > release interval has elapsed (and elect a release manager). >> > >> > - Jie >> > >> > On Wed, Mar 14, 2018 at 9:51 AM, Zhitao Li >> wrote: >> > >> >> An additional data point is how long it takes from first RC being cut >> to >> >> the final release tag vote passes. That probably indicates smoothness >> of >> >> the release process and how good the quality control measures. >> >> >> >> I would argue for not delaying release for new features and align wit= h >> the >> >> schedule we declared on policy. That makes upstream projects easier t= o >> >> gauge when a feature will be ready and when they can try it out. >> >> >> >> On Tue, Mar 13, 2018 at 3:10 PM, Greg Mann wrote= : >> >> >> >> > Hi folks, >> >> > During the recent API working group meeting [1], we discussed the >> >> release >> >> > schedule. This has been a recurring topic of discussion in the >> developer >> >> > sync meetings, and while our official policy still specifies >> time-based >> >> > releases at a bi-monthly cadence, in practice we tend to gate our >> >> releases >> >> > on the completion of certain features, and our releases go out on a >> >> > less-frequent basis. Here are the dates of our last few release blo= g >> >> posts, >> >> > which I'm assuming correlate pretty well with the actual release >> dates: >> >> > >> >> > 1.5.0: 2/8/18 >> >> > 1.4.0: 9/18/17 >> >> > 1.3.0: 6/7/17 >> >> > 1.2.0: 3/8/17 >> >> > 1.1.0: 11/10/16 >> >> > >> >> > Our current cadence seems to be around 3-4 months between releases, >> >> while >> >> > our documentation states that we release every two months [2]. My >> >> primary >> >> > motivation here is to bring our documented policy in line with our >> >> > practice, whatever that may be. Do people think that we should >> attempt >> >> to >> >> > bring our release cadence more in line with our current stated >> policy, >> >> or >> >> > should the policy be changed to reflect our current practice? >> >> > >> >> > If we were to attempt to align with our stated policy for 1.6.0, >> then we >> >> > would release around April 8, which would probably mean cutting an = RC >> >> > sometime around the end of March or beginning of April. This is ver= y >> >> soon! >> >> > :) >> >> > >> >> >> >> > I'm currently working with Gast=C3=B3n on offer operation feedback,= and >> I'm >> >> not >> >> > sure that we would have it ready in time for an early April release >> >> date. >> >> > Personally, I would be OK with this, since we could land the featur= e >> in >> >> > 1.7.0 in June. However, I'm not sure how well this schedule would >> work >> >> for >> >> > the features that other people are currently working on. >> >> > >> >> >> >> A highly important feature our org need is resizing of persistent >> volume. >> >> I >> >> think it has a good chance to make the stated 1.6 schedule. >> >> >> >> >> >> > >> >> > I'm curious to hear people's thoughts on this, developers and users >> >> alike! >> >> > >> >> > Cheers, >> >> > Greg >> >> > >> >> > >> >> > [1] https://docs.google.com/document/d/1JrF7pA6gcBZ6iyeP5YgD >> >> > G62ifn0cZIBWw1f_Ler6fLM/edit# >> >> > [2] http://mesos.apache.org/documentation/latest/versioning/ >> >> > #release-schedule >> >> > >> >> >> >> >> >> >> >> -- >> >> Cheers, >> >> >> >> Zhitao Li >> >> >> > >> > >> > > --089e082fa6d00e7be00568510b5f--