+1 to user-centric view. Agree with Alan - if we keep a steady cadence with the branch cuts then it can just be on us to optimize our process for getting it shipped.
I don't think users are too bothered by exact time gap unless it is too slow, so if this puts some at 4 weeks or even 2 weeks no one will be upset. It is also nice if there is a comparable amount of change between releases, another reason to branch every 6 weeks. And finally, if there is a contributor that is implementing something and wants to get it to users, it should be able to arrive in <= 6 weeks. That means that if a release sits on a branch/review for a long time, it should not really slow down other things done on master in that time. Kenn On Mon, Jun 25, 2018 at 11:48 AM Alan Myrvold <[email protected]> wrote: > It would be a more predictable cadence to have a consistent timing between > when the release branches are cut, and not when the release is published. > > If 2.5.0 was cut on June 5, then 2.6.0 could be cut July 17? > > On Mon, Jun 25, 2018 at 10:57 AM Ahmet Altay <[email protected]> wrote: > >> >> >> On Mon, Jun 25, 2018 at 10:49 AM, Ahmet Altay <[email protected]> wrote: >> >>> JB, thank you for making this release happen. >>> >>> I noticed that python artifacts are not deployed to pypi yet. Would you >>> like me to do that? >>> >>> Thank you, >>> Ahmet >>> >>> On Sat, Jun 23, 2018 at 6:45 AM, Rafael Fernandez <[email protected]> >>> wrote: >>> >>>> Great news! Thanks so much to our Release Manager and everybody who >>>> helped iron out the wrinkles! >>>> >>>> If you haven't seen it already, look for the thread "[PROPOSAL] Add a >>>> blog post for Beam release 2.5.0 >>>> " [1] >>>> in dev@ - Alexey Romanenko has put together a very nice summary of >>>> all the good stuff in 2.5.0. >>>> >>>> [1] >>>> https://lists.apache.org/thread.html/ae3284ca051b800b3edd73ad0f7f62344e26d3957b46794149bf1fb2@%3Cdev.beam.apache.org%3E >>>> >>>> >>>> " >>>> >>>> On Fri, Jun 22, 2018 at 8:33 PM Jean-Baptiste Onofré <[email protected]> >>>> wrote: >>>> >>>>> I meant August (not July) for next release cycle. >>>>> >>>>> Regards >>>>> JB >>>>> >>>>> On 23/06/2018 05:17, Jean-Baptiste Onofré wrote: >>>>> > Hi all, >>>>> > >>>>> > I'm happy to announce that we have unanimously approved this release. >>>>> > >>>>> > There are 12 approving votes, 5 of which are binding: >>>>> > * Ahmet Altay >>>>> > * Jean-Baptiste Onofré >>>>> > * Lukasz Cwik >>>>> > * Reuven Lax >>>>> > * Robert Bradshaw >>>>> > >>>>> > There are no disapproving votes. >>>>> > >>>>> > I'm finalizing the release. >>>>> > >>>>> > Thanks everyone! >>>>> > >>>>> > The 2.6.0 release process is expected to begin in 6 weeks. So we >>>>> should >>>>> > start the Jira triage on Saturday, 4th July and I would like to start >>>>> > the release process on Tuesday 7th. >>>>> >>>> >> My understanding was that there will be a release every 6 weeks. It seems >> like with this plan (to start release process on August 7), the >> understanding is that we will have 6 weeks between a release is out and the >> start of the next release process. My take is, we need to have a user >> centric view and a make promise to release every X weeks. If X=6 is not >> sustainable we can discuss. However, having X weeks in between a release >> cut and release start will result in unpredictable release dates. >> >> What do you think? >> >> >>> > >>>>> > Regards >>>>> > JB >>>>> > >>>>> > >>>>> > On 17/06/2018 07:18, Jean-Baptiste Onofré wrote: >>>>> >> Hi everyone, >>>>> >> >>>>> >> Please review and vote on the release candidate #2 for the version >>>>> >> 2.5.0, as follows: >>>>> >> >>>>> >> [ ] +1, Approve the release >>>>> >> [ ] -1, Do not approve the release (please provide specific >>>>> comments) >>>>> >> >>>>> >> NB: this is the first release using Gradle, so don't be too harsh >>>>> ;) A >>>>> >> PR about the release guide will follow thanks to this release. >>>>> >> >>>>> >> The complete staging area is available for your review, which >>>>> includes: >>>>> >> * JIRA release notes [1], >>>>> >> * the official Apache source release to be deployed to >>>>> dist.apache.org >>>>> >> [2], which is signed with the key with fingerprint C8282E76 [3], >>>>> >> * all artifacts to be deployed to the Maven Central Repository [4], >>>>> >> * source code tag "v2.5.0-RC2" [5], >>>>> >> * website pull request listing the release and publishing the API >>>>> >> reference manual [6]. >>>>> >> * Java artifacts were built with Gradle 4.7 (wrapper) and >>>>> OpenJDK/Oracle >>>>> >> JDK 1.8.0_172 (Oracle Corporation 25.172-b11). >>>>> >> * Python artifacts are deployed along with the source release to the >>>>> >> dist.apache.org [2]. >>>>> >> >>>>> >> The vote will be open for at least 72 hours. It is adopted by >>>>> majority >>>>> >> approval, with at least 3 PMC affirmative votes. >>>>> >> >>>>> >> Thanks, >>>>> >> JB >>>>> >> >>>>> >> [1] >>>>> >> >>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527&version=12342847 >>>>> >> [2] https://dist.apache.org/repos/dist/dev/beam/2.5.0/ >>>>> >> [3] https://dist.apache.org/repos/dist/release/beam/KEYS >>>>> >> [4] >>>>> https://repository.apache.org/content/repositories/orgapachebeam-1043/ >>>>> >> [5] https://github.com/apache/beam/tree/v2.5.0-RC2 >>>>> >> [6] https://github.com/apache/beam-site/pull/463 >>>>> >> >>>>> > >>>>> >>>>> -- >>>>> Jean-Baptiste Onofré >>>>> [email protected] >>>>> http://blog.nanthrax.net >>>>> Talend - http://www.talend.com >>>>> >>>> >>> >>
