+1 to delay 2 weeks as Ahmet proposes. We can cut the branch in two
weeks in a more stable shape doing it right now is not a good idea.
We can justify the delay on the impact of transitioning the build system.


On Wed, Apr 11, 2018 at 10:35 PM, Ahmet Altay <[email protected]> wrote:
> +1 to delaying 2 weeks.
>
> I think it will be prudent to wait in this case. There is too much in flux
> with Gradle migration currently and based on Scott's latest update I think
> we will be in a more stable state in 2 weeks. Last Beam release date was
> 3/20 and our plan was to make a release every 6 weeks. Even if we start
> cutting a release in 2 weeks (~4/26), we will have more than a week to
> finish that release. Even if that is not enough time to finish a release it
> will put is in the proximity of the 5/5 target date. I prefer that option,
> to another potential release with Maven.
>
> On Wed, Apr 11, 2018 at 1:22 PM, Romain Manni-Bucau <[email protected]>
> wrote:
>>
>> Any hope the release is on central before the 30th?
>
>
> I do not think this was the plan to begin with. The time between the
> previous release and 4/30 is less than 6 weeks.
>
>>
>>
>> Le 11 avr. 2018 22:02, "Robert Bradshaw" <[email protected]> a écrit :
>>>
>>> +1 to keeping up the regular release cycle, but I don't think it makes
>>> sense to cut until we're ready to actively work on the release. A cut date
>>> two weeks from now seems fine (unless someone else is volunteering to do it
>>> this time around).
>>>
>>> That being said, a dry run using gradle now may make a lot of sense,
>>> giving us a couple of weeks to iron out the kinks, if any.
>>>
>>> On Wed, Apr 11, 2018 at 12:58 PM Chamikara Jayalath
>>> <[email protected]> wrote:
>>>>
>>>> Hi JB,
>>>>
>>>> Please note that I opened a blocker [1] (working on it) and looks like
>>>> we have several other JIRAs marked for 2.5.0. So +1 for waiting for two
>>>> weeks (or till JIRAs are resolved or moved off the list).
>>>>
>>>> Thanks,
>>>> Cham
>>>>
>>>> [1] https://issues.apache.org/jira/browse/BEAM-3991
>>>> [2]
>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20BEAM%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%202.5.0%20ORDER%20BY%20priority%20DESC
>>>>
>>>> On Wed, Apr 11, 2018 at 12:28 PM Jean-Baptiste Onofré <[email protected]>
>>>> wrote:
>>>>>
>>>>> Hi guys,
>>>>>
>>>>> Due to the last work, I think it makes sense to try a release using
>>>>> Gradle. If it doesn't work smoothly, we will rollback to Maven, and
>>>>> maybe in that case, we should ask ourselves if Gradle is really a good
>>>>> alternative for now.
>>>>>
>>>>> I'm in vacation tomorrow morning for 2 weeks. I can cut the release
>>>>> tomorrow end of the morning (my time). But in the case we need some
>>>>> additional PR merges or we have some work in progress, I'm proposing to
>>>>> postpone 2.5.0 release for the end of this month (in two weeks). If
>>>>> someone is volunteer to tackle this release, please, let us know.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 06/04/2018 10:48, Jean-Baptiste Onofré wrote:
>>>>> > Hi guys,
>>>>> >
>>>>> > Apache Beam 2.4.0 has been released on March 20th.
>>>>> >
>>>>> > According to our cycle of release (roughly 6 weeks), we should think
>>>>> > about 2.5.0.
>>>>> >
>>>>> > I'm volunteer to tackle this release.
>>>>> >
>>>>> > I'm proposing the following items:
>>>>> >
>>>>> > 1. We start the Jira triage now, up to Tuesday
>>>>> > 2. I would like to cut the release on Tuesday night (Europe time)
>>>>> > 2bis. I think it's wiser to still use Maven for this release. Do you
>>>>> > think we
>>>>> > will be ready to try a release with Gradle ?
>>>>> >
>>>>> > After this release, I would like a discussion about:
>>>>> > 1. Gradle release (if we release 2.5.0 with Maven)
>>>>> > 2. Isolate release cycle per Beam part. I think it would be
>>>>> > interesting to have
>>>>> > different release cycle: SDKs, DSLs, Runners, IOs. That's another
>>>>> > discussion, I
>>>>> > will start a thread about that.
>>>>> >
>>>>> > Thoughts ?
>>>>> >
>>>>> > Regards
>>>>> > JB
>>>>> >
>
>

Reply via email to