Re: [PROPOSAL] Preparing for Beam 2.12.0 release

[Andrew Pilloud]

It seems like there was some confusion around when the branch cut was going
to happen. I cut the branch yesterday, but a dozen release blocking fixes
went in immediately after. I recut the branch today, one day late, at
1d9daf1

.

There are currently 3 release blocking issues
. I plan to
cut the first RC on March 3rd, so get your cherry-picks in by end of day on
March 2nd.

Andrew

On Mon, Mar 18, 2019 at 9:14 AM Etienne Chauchot 
wrote:

> Sounds great, thanks for volunteering to do the release.
>
> Etienne
>
> Le mercredi 13 mars 2019 à 12:08 -0700, Andrew Pilloud a écrit :
>
> Hello Beam community!
>
> Beam 2.12 release branch cut date is March 27th according to the release
> calendar [1]. I would like to volunteer myself to do this release. I intend
> to cut the branch as planned on March 27th and cherrypick fixes if needed.
>
> If you have releasing blocking issues for 2.12 please mark their "Fix
> Version" as 2.12.0. Kenn created a 2.13.0 release in JIRA in case you
> would like to move any non-blocking issues to that version.
>
> Does this sound reasonable?
>
> Andrew
>
> [1]
> https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com=America%2FLos_Angeles
>
>

Re: [PROPOSAL] Preparing for Beam 2.12.0 release

[Andrew Pilloud]

Yes, that is what I meant. Sorry about mixing up the month!

On Thu, Mar 28, 2019 at 9:26 AM Robert Burke  wrote:

> I'm going to go out on a limb and assume you mean first RC cut on April
> 3rd, and the Cherry-pick deadline EoD (PST?) April 2nd.
>
> On Thu, 28 Mar 2019 at 09:23, Andrew Pilloud  wrote:
>
>> It seems like there was some confusion around when the branch cut was
>> going to happen. I cut the branch yesterday, but a dozen release blocking
>> fixes went in immediately after. I recut the branch today, one day late, at
>> 1d9daf1
>> 
>> .
>>
>> There are currently 3 release blocking issues
>> . I plan
>> to cut the first RC on March 3rd, so get your cherry-picks in by end of day
>> on March 2nd.
>>
>> Andrew
>>
>> On Mon, Mar 18, 2019 at 9:14 AM Etienne Chauchot 
>> wrote:
>>
>>> Sounds great, thanks for volunteering to do the release.
>>>
>>> Etienne
>>>
>>> Le mercredi 13 mars 2019 à 12:08 -0700, Andrew Pilloud a écrit :
>>>
>>> Hello Beam community!
>>>
>>> Beam 2.12 release branch cut date is March 27th according to the
>>> release calendar [1]. I would like to volunteer myself to do this release.
>>> I intend to cut the branch as planned on March 27th and cherrypick fixes if
>>> needed.
>>>
>>> If you have releasing blocking issues for 2.12 please mark their "Fix
>>> Version" as 2.12.0. Kenn created a 2.13.0 release in JIRA in case you
>>> would like to move any non-blocking issues to that version.
>>>
>>> Does this sound reasonable?
>>>
>>> Andrew
>>>
>>> [1]
>>> https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com=America%2FLos_Angeles
>>>
>>>

Re: [PROPOSAL] Preparing for Beam 2.12.0 release

[Robert Burke]

I'm going to go out on a limb and assume you mean first RC cut on April
3rd, and the Cherry-pick deadline EoD (PST?) April 2nd.

On Thu, 28 Mar 2019 at 09:23, Andrew Pilloud  wrote:

> It seems like there was some confusion around when the branch cut was
> going to happen. I cut the branch yesterday, but a dozen release blocking
> fixes went in immediately after. I recut the branch today, one day late, at
> 1d9daf1
> 
> .
>
> There are currently 3 release blocking issues
> . I plan
> to cut the first RC on March 3rd, so get your cherry-picks in by end of day
> on March 2nd.
>
> Andrew
>
> On Mon, Mar 18, 2019 at 9:14 AM Etienne Chauchot 
> wrote:
>
>> Sounds great, thanks for volunteering to do the release.
>>
>> Etienne
>>
>> Le mercredi 13 mars 2019 à 12:08 -0700, Andrew Pilloud a écrit :
>>
>> Hello Beam community!
>>
>> Beam 2.12 release branch cut date is March 27th according to the release
>> calendar [1]. I would like to volunteer myself to do this release. I intend
>> to cut the branch as planned on March 27th and cherrypick fixes if needed.
>>
>> If you have releasing blocking issues for 2.12 please mark their "Fix
>> Version" as 2.12.0. Kenn created a 2.13.0 release in JIRA in case you
>> would like to move any non-blocking issues to that version.
>>
>> Does this sound reasonable?
>>
>> Andrew
>>
>> [1]
>> https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com=America%2FLos_Angeles
>>
>>

Re: [PROPOSAL] Preparing for Beam 2.12.0 release

[Etienne Chauchot]

Sounds great, thanks for volunteering to do the release.
Etienne
Le mercredi 13 mars 2019 à 12:08 -0700, Andrew Pilloud a écrit :
> Hello Beam community!
> Beam 2.12 release branch cut date is March 27th according to the release 
> calendar [1]. I would like to volunteer
> myself to do this release. I intend to cut the branch as planned on March 
> 27th and cherrypick fixes if needed.
> 
> If you have releasing blocking issues for 2.12 please mark their "Fix 
> Version" as 2.12.0. Kenn created a 2.13.0
> release in JIRA in case you would like to move any non-blocking issues to 
> that version.
> 
> Does this sound reasonable?
> 
> Andrew
> 
> [1] 
> https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com=America%2FLos_Angeles

Re: [PROPOSAL] Preparing for Beam 2.12.0 release

[Robert Bradshaw]

I agree with Kenn on both accounts. We can (and should) keep 2.7.x
alive with an immanent 2.7.1 release, and choose the next one at a
future date based on actual experience with an existing release.

On Fri, Mar 15, 2019 at 5:36 PM Ahmet Altay  wrote:
>
> +1 to extending 2.7.x LTS lifetime for a little longer and simultaneously 
> making a 2.7.1 release.
>
> On Fri, Mar 15, 2019 at 9:32 AM Kenneth Knowles  wrote:
>>
>> We actually have some issues queued up for 2.7.1, and IMO it makes sense to 
>> extend 2.7 since the 6 month period was just a pilot and like you say we 
>> haven't really exercised LTS.
>>
>> Re 2.12.0 I strongly feel LTS should be designated after a release has seen 
>> some use. If we extend 2.7 for another while then we will have some 
>> candidate by the time it expires. (2.8, 2.9, 2.10 all have major issues, 
>> while 2.11 and 2.12 are untried)
>>
>> Kenn
>>
>> On Fri, Mar 15, 2019 at 7:50 AM Thomas Weise  wrote:
>>>
>>> Given no LTS activity for 2.7.x - do we really need it?
>>>
>>>
>>> On Fri, Mar 15, 2019 at 6:54 AM Ismaël Mejía  wrote:

 After looking at the dates it seems that 2.12 should be the next LTS
 since it will be exactly 6 months after the release of 2.7.0. Anyone
 has comments, or prefer to do the LTS better for the next version
 (2.13) ?

 On Thu, Mar 14, 2019 at 12:13 PM Michael Luckey  
 wrote:
 >
 > @mxm
 >
 > Sure we should. Unfortunately the scripts to not have any '--dry-run' 
 > toggle. Implementing this seemed not too easy on first sight, as those 
 > release scripts do assume committed outputs of their predecessors and 
 > are not yet in the shape to be parameterised.
 >
 > So here is what I did:
 > 1. As I did not wanted the scripts to do 'sudo' installs on my machine, 
 > I first created a docker image with required prerequisites.
 > 2. Cloned beam to that machine (to get the release.scripts)
 > 3. Edited the places which seemed to call to the outside
 > - disabled any git push
 > - changed git url to point to some copy on local filesystem to pull 
 > required changes from there
 > - changed './gradlew' build to './gradlew assemble' as build will 
 > not work on docker anyway
 > - changed publish to publishToMavenLocal
 > - probably some more changes to ensure I do not write to remote
 > 4. run the scripts
 >
 > What I missed out:
 > 1. There is some communication with svn (signing artefacts downloaded 
 > from svn and committing). I just skipped those steps, as I was just too 
 > scared to miss some commit and doing an accidental push to some remote 
 > system (where I am hopefully not authorised anyway without doing proper 
 > authentication)
 >
 > If you believe I missed something which could be tested in advance, I d 
 > happily do more testing to ensure a smooth release process.
 >
 > michel
 >
 > On Thu, Mar 14, 2019 at 11:23 AM Maximilian Michels  
 > wrote:
 >>
 >> Hi Andrew,
 >>
 >> Sounds good. Thank you for being the release manager.
 >>
 >> @Michael Shall we perform some dry-run release testing for ensuring
 >> Gradle 5 compatibility?
 >>
 >> Thanks,
 >> Max
 >>
 >> On 14.03.19 00:28, Michael Luckey wrote:
 >> > Sounds good. Thanks for volunteering.
 >> >
 >> > Just as a side note: @aaltay had trouble releasing caused by the 
 >> > switch
 >> > to gradle5. Although that should be fixed now, you will be the first
 >> > using those changes in production. So if you encounter any issues. do
 >> > not hesitate to blame and contact me. Also I am currently looking into
 >> > some improvements to the process suggested by @kenn. So your feedback 
 >> > on
 >> > the current state would be greatly appreciated. I hope to get at least
 >> > https://issues.apache.org/jira/browse/BEAM-6798 done until then.
 >> >
 >> > Thanks again,
 >> >
 >> > michel
 >> >
 >> > On Wed, Mar 13, 2019 at 8:13 PM Ahmet Altay >>> >> > > wrote:
 >> >
 >> > Sounds great, thank you!
 >> >
 >> > On Wed, Mar 13, 2019 at 12:09 PM Andrew Pilloud 
 >> > >>> >> > > wrote:
 >> >
 >> > Hello Beam community!
 >> >
 >> > Beam 2.12 release branch cut date is March 27th according to 
 >> > the
 >> > release calendar [1]. I would like to volunteer myself to do
 >> > this release. I intend to cut the branch as planned on March
 >> > 27th and cherrypick fixes if needed.
 >> >
 >> > If you have releasing blocking issues for 2.12 please mark 
 >> > their
 >> > "Fix Version" as 2.12.0. Kenn created a 2.13.0 release in JIRA
 >> > in case you would like to move any non-blocking issues to that
 >> 

Re: [PROPOSAL] Preparing for Beam 2.12.0 release

[Ahmet Altay]

+1 to extending 2.7.x LTS lifetime for a little longer and simultaneously
making a 2.7.1 release.

On Fri, Mar 15, 2019 at 9:32 AM Kenneth Knowles  wrote:

> We actually have some issues queued up for 2.7.1, and IMO it makes sense
> to extend 2.7 since the 6 month period was just a pilot and like you say we
> haven't really exercised LTS.
>
> Re 2.12.0 I strongly feel LTS should be designated after a release has
> seen some use. If we extend 2.7 for another while then we will have some
> candidate by the time it expires. (2.8, 2.9, 2.10 all have major issues,
> while 2.11 and 2.12 are untried)
>
> Kenn
>
> On Fri, Mar 15, 2019 at 7:50 AM Thomas Weise  wrote:
>
>> Given no LTS activity for 2.7.x - do we really need it?
>>
>>
>> On Fri, Mar 15, 2019 at 6:54 AM Ismaël Mejía  wrote:
>>
>>> After looking at the dates it seems that 2.12 should be the next LTS
>>> since it will be exactly 6 months after the release of 2.7.0. Anyone
>>> has comments, or prefer to do the LTS better for the next version
>>> (2.13) ?
>>>
>>> On Thu, Mar 14, 2019 at 12:13 PM Michael Luckey 
>>> wrote:
>>> >
>>> > @mxm
>>> >
>>> > Sure we should. Unfortunately the scripts to not have any '--dry-run'
>>> toggle. Implementing this seemed not too easy on first sight, as those
>>> release scripts do assume committed outputs of their predecessors and are
>>> not yet in the shape to be parameterised.
>>> >
>>> > So here is what I did:
>>> > 1. As I did not wanted the scripts to do 'sudo' installs on my
>>> machine, I first created a docker image with required prerequisites.
>>> > 2. Cloned beam to that machine (to get the release.scripts)
>>> > 3. Edited the places which seemed to call to the outside
>>> > - disabled any git push
>>> > - changed git url to point to some copy on local filesystem to
>>> pull required changes from there
>>> > - changed './gradlew' build to './gradlew assemble' as build will
>>> not work on docker anyway
>>> > - changed publish to publishToMavenLocal
>>> > - probably some more changes to ensure I do not write to remote
>>> > 4. run the scripts
>>> >
>>> > What I missed out:
>>> > 1. There is some communication with svn (signing artefacts downloaded
>>> from svn and committing). I just skipped those steps, as I was just too
>>> scared to miss some commit and doing an accidental push to some remote
>>> system (where I am hopefully not authorised anyway without doing proper
>>> authentication)
>>> >
>>> > If you believe I missed something which could be tested in advance, I
>>> d happily do more testing to ensure a smooth release process.
>>> >
>>> > michel
>>> >
>>> > On Thu, Mar 14, 2019 at 11:23 AM Maximilian Michels 
>>> wrote:
>>> >>
>>> >> Hi Andrew,
>>> >>
>>> >> Sounds good. Thank you for being the release manager.
>>> >>
>>> >> @Michael Shall we perform some dry-run release testing for ensuring
>>> >> Gradle 5 compatibility?
>>> >>
>>> >> Thanks,
>>> >> Max
>>> >>
>>> >> On 14.03.19 00:28, Michael Luckey wrote:
>>> >> > Sounds good. Thanks for volunteering.
>>> >> >
>>> >> > Just as a side note: @aaltay had trouble releasing caused by the
>>> switch
>>> >> > to gradle5. Although that should be fixed now, you will be the first
>>> >> > using those changes in production. So if you encounter any issues.
>>> do
>>> >> > not hesitate to blame and contact me. Also I am currently looking
>>> into
>>> >> > some improvements to the process suggested by @kenn. So your
>>> feedback on
>>> >> > the current state would be greatly appreciated. I hope to get at
>>> least
>>> >> > https://issues.apache.org/jira/browse/BEAM-6798 done until then.
>>> >> >
>>> >> > Thanks again,
>>> >> >
>>> >> > michel
>>> >> >
>>> >> > On Wed, Mar 13, 2019 at 8:13 PM Ahmet Altay >> >> > > wrote:
>>> >> >
>>> >> > Sounds great, thank you!
>>> >> >
>>> >> > On Wed, Mar 13, 2019 at 12:09 PM Andrew Pilloud <
>>> apill...@google.com
>>> >> > > wrote:
>>> >> >
>>> >> > Hello Beam community!
>>> >> >
>>> >> > Beam 2.12 release branch cut date is March 27th according
>>> to the
>>> >> > release calendar [1]. I would like to volunteer myself to do
>>> >> > this release. I intend to cut the branch as planned on March
>>> >> > 27th and cherrypick fixes if needed.
>>> >> >
>>> >> > If you have releasing blocking issues for 2.12 please mark
>>> their
>>> >> > "Fix Version" as 2.12.0. Kenn created a 2.13.0 release in
>>> JIRA
>>> >> > in case you would like to move any non-blocking issues to
>>> that
>>> >> > version.
>>> >> >
>>> >> > Does this sound reasonable?
>>> >> >
>>> >> > Andrew
>>> >> >
>>> >> > [1]
>>> >> >
>>> https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com=America%2FLos_Angeles
>>> >> >
>>>
>>

Re: [PROPOSAL] Preparing for Beam 2.12.0 release

[Kenneth Knowles]

We actually have some issues queued up for 2.7.1, and IMO it makes sense to
extend 2.7 since the 6 month period was just a pilot and like you say we
haven't really exercised LTS.

Re 2.12.0 I strongly feel LTS should be designated after a release has seen
some use. If we extend 2.7 for another while then we will have some
candidate by the time it expires. (2.8, 2.9, 2.10 all have major issues,
while 2.11 and 2.12 are untried)

Kenn

On Fri, Mar 15, 2019 at 7:50 AM Thomas Weise  wrote:

> Given no LTS activity for 2.7.x - do we really need it?
>
>
> On Fri, Mar 15, 2019 at 6:54 AM Ismaël Mejía  wrote:
>
>> After looking at the dates it seems that 2.12 should be the next LTS
>> since it will be exactly 6 months after the release of 2.7.0. Anyone
>> has comments, or prefer to do the LTS better for the next version
>> (2.13) ?
>>
>> On Thu, Mar 14, 2019 at 12:13 PM Michael Luckey 
>> wrote:
>> >
>> > @mxm
>> >
>> > Sure we should. Unfortunately the scripts to not have any '--dry-run'
>> toggle. Implementing this seemed not too easy on first sight, as those
>> release scripts do assume committed outputs of their predecessors and are
>> not yet in the shape to be parameterised.
>> >
>> > So here is what I did:
>> > 1. As I did not wanted the scripts to do 'sudo' installs on my machine,
>> I first created a docker image with required prerequisites.
>> > 2. Cloned beam to that machine (to get the release.scripts)
>> > 3. Edited the places which seemed to call to the outside
>> > - disabled any git push
>> > - changed git url to point to some copy on local filesystem to pull
>> required changes from there
>> > - changed './gradlew' build to './gradlew assemble' as build will
>> not work on docker anyway
>> > - changed publish to publishToMavenLocal
>> > - probably some more changes to ensure I do not write to remote
>> > 4. run the scripts
>> >
>> > What I missed out:
>> > 1. There is some communication with svn (signing artefacts downloaded
>> from svn and committing). I just skipped those steps, as I was just too
>> scared to miss some commit and doing an accidental push to some remote
>> system (where I am hopefully not authorised anyway without doing proper
>> authentication)
>> >
>> > If you believe I missed something which could be tested in advance, I d
>> happily do more testing to ensure a smooth release process.
>> >
>> > michel
>> >
>> > On Thu, Mar 14, 2019 at 11:23 AM Maximilian Michels 
>> wrote:
>> >>
>> >> Hi Andrew,
>> >>
>> >> Sounds good. Thank you for being the release manager.
>> >>
>> >> @Michael Shall we perform some dry-run release testing for ensuring
>> >> Gradle 5 compatibility?
>> >>
>> >> Thanks,
>> >> Max
>> >>
>> >> On 14.03.19 00:28, Michael Luckey wrote:
>> >> > Sounds good. Thanks for volunteering.
>> >> >
>> >> > Just as a side note: @aaltay had trouble releasing caused by the
>> switch
>> >> > to gradle5. Although that should be fixed now, you will be the first
>> >> > using those changes in production. So if you encounter any issues. do
>> >> > not hesitate to blame and contact me. Also I am currently looking
>> into
>> >> > some improvements to the process suggested by @kenn. So your
>> feedback on
>> >> > the current state would be greatly appreciated. I hope to get at
>> least
>> >> > https://issues.apache.org/jira/browse/BEAM-6798 done until then.
>> >> >
>> >> > Thanks again,
>> >> >
>> >> > michel
>> >> >
>> >> > On Wed, Mar 13, 2019 at 8:13 PM Ahmet Altay > >> > > wrote:
>> >> >
>> >> > Sounds great, thank you!
>> >> >
>> >> > On Wed, Mar 13, 2019 at 12:09 PM Andrew Pilloud <
>> apill...@google.com
>> >> > > wrote:
>> >> >
>> >> > Hello Beam community!
>> >> >
>> >> > Beam 2.12 release branch cut date is March 27th according to
>> the
>> >> > release calendar [1]. I would like to volunteer myself to do
>> >> > this release. I intend to cut the branch as planned on March
>> >> > 27th and cherrypick fixes if needed.
>> >> >
>> >> > If you have releasing blocking issues for 2.12 please mark
>> their
>> >> > "Fix Version" as 2.12.0. Kenn created a 2.13.0 release in
>> JIRA
>> >> > in case you would like to move any non-blocking issues to
>> that
>> >> > version.
>> >> >
>> >> > Does this sound reasonable?
>> >> >
>> >> > Andrew
>> >> >
>> >> > [1]
>> >> >
>> https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com=America%2FLos_Angeles
>> >> >
>>
>

Re: [PROPOSAL] Preparing for Beam 2.12.0 release

[Thomas Weise]

Given no LTS activity for 2.7.x - do we really need it?


On Fri, Mar 15, 2019 at 6:54 AM Ismaël Mejía  wrote:

> After looking at the dates it seems that 2.12 should be the next LTS
> since it will be exactly 6 months after the release of 2.7.0. Anyone
> has comments, or prefer to do the LTS better for the next version
> (2.13) ?
>
> On Thu, Mar 14, 2019 at 12:13 PM Michael Luckey 
> wrote:
> >
> > @mxm
> >
> > Sure we should. Unfortunately the scripts to not have any '--dry-run'
> toggle. Implementing this seemed not too easy on first sight, as those
> release scripts do assume committed outputs of their predecessors and are
> not yet in the shape to be parameterised.
> >
> > So here is what I did:
> > 1. As I did not wanted the scripts to do 'sudo' installs on my machine,
> I first created a docker image with required prerequisites.
> > 2. Cloned beam to that machine (to get the release.scripts)
> > 3. Edited the places which seemed to call to the outside
> > - disabled any git push
> > - changed git url to point to some copy on local filesystem to pull
> required changes from there
> > - changed './gradlew' build to './gradlew assemble' as build will
> not work on docker anyway
> > - changed publish to publishToMavenLocal
> > - probably some more changes to ensure I do not write to remote
> > 4. run the scripts
> >
> > What I missed out:
> > 1. There is some communication with svn (signing artefacts downloaded
> from svn and committing). I just skipped those steps, as I was just too
> scared to miss some commit and doing an accidental push to some remote
> system (where I am hopefully not authorised anyway without doing proper
> authentication)
> >
> > If you believe I missed something which could be tested in advance, I d
> happily do more testing to ensure a smooth release process.
> >
> > michel
> >
> > On Thu, Mar 14, 2019 at 11:23 AM Maximilian Michels 
> wrote:
> >>
> >> Hi Andrew,
> >>
> >> Sounds good. Thank you for being the release manager.
> >>
> >> @Michael Shall we perform some dry-run release testing for ensuring
> >> Gradle 5 compatibility?
> >>
> >> Thanks,
> >> Max
> >>
> >> On 14.03.19 00:28, Michael Luckey wrote:
> >> > Sounds good. Thanks for volunteering.
> >> >
> >> > Just as a side note: @aaltay had trouble releasing caused by the
> switch
> >> > to gradle5. Although that should be fixed now, you will be the first
> >> > using those changes in production. So if you encounter any issues. do
> >> > not hesitate to blame and contact me. Also I am currently looking into
> >> > some improvements to the process suggested by @kenn. So your feedback
> on
> >> > the current state would be greatly appreciated. I hope to get at least
> >> > https://issues.apache.org/jira/browse/BEAM-6798 done until then.
> >> >
> >> > Thanks again,
> >> >
> >> > michel
> >> >
> >> > On Wed, Mar 13, 2019 at 8:13 PM Ahmet Altay  >> > > wrote:
> >> >
> >> > Sounds great, thank you!
> >> >
> >> > On Wed, Mar 13, 2019 at 12:09 PM Andrew Pilloud <
> apill...@google.com
> >> > > wrote:
> >> >
> >> > Hello Beam community!
> >> >
> >> > Beam 2.12 release branch cut date is March 27th according to
> the
> >> > release calendar [1]. I would like to volunteer myself to do
> >> > this release. I intend to cut the branch as planned on March
> >> > 27th and cherrypick fixes if needed.
> >> >
> >> > If you have releasing blocking issues for 2.12 please mark
> their
> >> > "Fix Version" as 2.12.0. Kenn created a 2.13.0 release in JIRA
> >> > in case you would like to move any non-blocking issues to that
> >> > version.
> >> >
> >> > Does this sound reasonable?
> >> >
> >> > Andrew
> >> >
> >> > [1]
> >> >
> https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com=America%2FLos_Angeles
> >> >
>

Re: [PROPOSAL] Preparing for Beam 2.12.0 release

[Ismaël Mejía]

After looking at the dates it seems that 2.12 should be the next LTS
since it will be exactly 6 months after the release of 2.7.0. Anyone
has comments, or prefer to do the LTS better for the next version
(2.13) ?

On Thu, Mar 14, 2019 at 12:13 PM Michael Luckey  wrote:
>
> @mxm
>
> Sure we should. Unfortunately the scripts to not have any '--dry-run' toggle. 
> Implementing this seemed not too easy on first sight, as those release 
> scripts do assume committed outputs of their predecessors and are not yet in 
> the shape to be parameterised.
>
> So here is what I did:
> 1. As I did not wanted the scripts to do 'sudo' installs on my machine, I 
> first created a docker image with required prerequisites.
> 2. Cloned beam to that machine (to get the release.scripts)
> 3. Edited the places which seemed to call to the outside
> - disabled any git push
> - changed git url to point to some copy on local filesystem to pull 
> required changes from there
> - changed './gradlew' build to './gradlew assemble' as build will not 
> work on docker anyway
> - changed publish to publishToMavenLocal
> - probably some more changes to ensure I do not write to remote
> 4. run the scripts
>
> What I missed out:
> 1. There is some communication with svn (signing artefacts downloaded from 
> svn and committing). I just skipped those steps, as I was just too scared to 
> miss some commit and doing an accidental push to some remote system (where I 
> am hopefully not authorised anyway without doing proper authentication)
>
> If you believe I missed something which could be tested in advance, I d 
> happily do more testing to ensure a smooth release process.
>
> michel
>
> On Thu, Mar 14, 2019 at 11:23 AM Maximilian Michels  wrote:
>>
>> Hi Andrew,
>>
>> Sounds good. Thank you for being the release manager.
>>
>> @Michael Shall we perform some dry-run release testing for ensuring
>> Gradle 5 compatibility?
>>
>> Thanks,
>> Max
>>
>> On 14.03.19 00:28, Michael Luckey wrote:
>> > Sounds good. Thanks for volunteering.
>> >
>> > Just as a side note: @aaltay had trouble releasing caused by the switch
>> > to gradle5. Although that should be fixed now, you will be the first
>> > using those changes in production. So if you encounter any issues. do
>> > not hesitate to blame and contact me. Also I am currently looking into
>> > some improvements to the process suggested by @kenn. So your feedback on
>> > the current state would be greatly appreciated. I hope to get at least
>> > https://issues.apache.org/jira/browse/BEAM-6798 done until then.
>> >
>> > Thanks again,
>> >
>> > michel
>> >
>> > On Wed, Mar 13, 2019 at 8:13 PM Ahmet Altay > > > wrote:
>> >
>> > Sounds great, thank you!
>> >
>> > On Wed, Mar 13, 2019 at 12:09 PM Andrew Pilloud > > > wrote:
>> >
>> > Hello Beam community!
>> >
>> > Beam 2.12 release branch cut date is March 27th according to the
>> > release calendar [1]. I would like to volunteer myself to do
>> > this release. I intend to cut the branch as planned on March
>> > 27th and cherrypick fixes if needed.
>> >
>> > If you have releasing blocking issues for 2.12 please mark their
>> > "Fix Version" as 2.12.0. Kenn created a 2.13.0 release in JIRA
>> > in case you would like to move any non-blocking issues to that
>> > version.
>> >
>> > Does this sound reasonable?
>> >
>> > Andrew
>> >
>> > [1]
>> > 
>> > https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com=America%2FLos_Angeles
>> >

Re: [PROPOSAL] Preparing for Beam 2.12.0 release

[Michael Luckey]

@mxm

Sure we should. Unfortunately the scripts to not have any '--dry-run'
toggle. Implementing this seemed not too easy on first sight, as those
release scripts do assume committed outputs of their predecessors and are
not yet in the shape to be parameterised.

So here is what I did:
1. As I did not wanted the scripts to do 'sudo' installs on my machine, I
first created a docker image with required prerequisites.
2. Cloned beam to that machine (to get the release.scripts)
3. Edited the places which seemed to call to the outside
- disabled any git push
- changed git url to point to some copy on local filesystem to pull
required changes from there
- changed './gradlew' build to './gradlew assemble' as build will not
work on docker anyway
- changed publish to publishToMavenLocal
- probably some more changes to ensure I do not write to remote
4. run the scripts

What I missed out:
1. There is some communication with svn (signing artefacts downloaded from
svn and committing). I just skipped those steps, as I was just too scared
to miss some commit and doing an accidental push to some remote system
(where I am hopefully not authorised anyway without doing proper
authentication)

If you believe I missed something which could be tested in advance, I d
happily do more testing to ensure a smooth release process.

michel

On Thu, Mar 14, 2019 at 11:23 AM Maximilian Michels  wrote:

> Hi Andrew,
>
> Sounds good. Thank you for being the release manager.
>
> @Michael Shall we perform some dry-run release testing for ensuring
> Gradle 5 compatibility?
>
> Thanks,
> Max
>
> On 14.03.19 00:28, Michael Luckey wrote:
> > Sounds good. Thanks for volunteering.
> >
> > Just as a side note: @aaltay had trouble releasing caused by the switch
> > to gradle5. Although that should be fixed now, you will be the first
> > using those changes in production. So if you encounter any issues. do
> > not hesitate to blame and contact me. Also I am currently looking into
> > some improvements to the process suggested by @kenn. So your feedback on
> > the current state would be greatly appreciated. I hope to get at least
> > https://issues.apache.org/jira/browse/BEAM-6798 done until then.
> >
> > Thanks again,
> >
> > michel
> >
> > On Wed, Mar 13, 2019 at 8:13 PM Ahmet Altay  > > wrote:
> >
> > Sounds great, thank you!
> >
> > On Wed, Mar 13, 2019 at 12:09 PM Andrew Pilloud  > > wrote:
> >
> > Hello Beam community!
> >
> > Beam 2.12 release branch cut date is March 27th according to the
> > release calendar [1]. I would like to volunteer myself to do
> > this release. I intend to cut the branch as planned on March
> > 27th and cherrypick fixes if needed.
> >
> > If you have releasing blocking issues for 2.12 please mark their
> > "Fix Version" as 2.12.0. Kenn created a 2.13.0 release in JIRA
> > in case you would like to move any non-blocking issues to that
> > version.
> >
> > Does this sound reasonable?
> >
> > Andrew
> >
> > [1]
> >
> https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com=America%2FLos_Angeles
> >
>

Re: [PROPOSAL] Preparing for Beam 2.12.0 release

[Maximilian Michels]

Hi Andrew,

Sounds good. Thank you for being the release manager.

@Michael Shall we perform some dry-run release testing for ensuring 
Gradle 5 compatibility?


Thanks,
Max

On 14.03.19 00:28, Michael Luckey wrote:

Sounds good. Thanks for volunteering.

Just as a side note: @aaltay had trouble releasing caused by the switch 
to gradle5. Although that should be fixed now, you will be the first 
using those changes in production. So if you encounter any issues. do 
not hesitate to blame and contact me. Also I am currently looking into 
some improvements to the process suggested by @kenn. So your feedback on 
the current state would be greatly appreciated. I hope to get at least 
https://issues.apache.org/jira/browse/BEAM-6798 done until then.


Thanks again,

michel

On Wed, Mar 13, 2019 at 8:13 PM Ahmet Altay > wrote:


Sounds great, thank you!

On Wed, Mar 13, 2019 at 12:09 PM Andrew Pilloud mailto:apill...@google.com>> wrote:

Hello Beam community!

Beam 2.12 release branch cut date is March 27th according to the
release calendar [1]. I would like to volunteer myself to do
this release. I intend to cut the branch as planned on March
27th and cherrypick fixes if needed.

If you have releasing blocking issues for 2.12 please mark their
"Fix Version" as 2.12.0. Kenn created a 2.13.0 release in JIRA
in case you would like to move any non-blocking issues to that
version.

Does this sound reasonable?

Andrew

[1]

https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com=America%2FLos_Angeles

Re: [PROPOSAL] Preparing for Beam 2.12.0 release

[Michael Luckey]

Sounds good. Thanks for volunteering.

Just as a side note: @aaltay had trouble releasing caused by the switch to
gradle5. Although that should be fixed now, you will be the first using
those changes in production. So if you encounter any issues. do not
hesitate to blame and contact me. Also I am currently looking into some
improvements to the process suggested by @kenn. So your feedback on the
current state would be greatly appreciated. I hope to get at least
https://issues.apache.org/jira/browse/BEAM-6798 done until then.

Thanks again,

michel

On Wed, Mar 13, 2019 at 8:13 PM Ahmet Altay  wrote:

> Sounds great, thank you!
>
> On Wed, Mar 13, 2019 at 12:09 PM Andrew Pilloud 
> wrote:
>
>> Hello Beam community!
>>
>> Beam 2.12 release branch cut date is March 27th according to the release
>> calendar [1]. I would like to volunteer myself to do this release. I intend
>> to cut the branch as planned on March 27th and cherrypick fixes if needed.
>>
>> If you have releasing blocking issues for 2.12 please mark their "Fix
>> Version" as 2.12.0. Kenn created a 2.13.0 release in JIRA in case you
>> would like to move any non-blocking issues to that version.
>>
>> Does this sound reasonable?
>>
>> Andrew
>>
>> [1]
>> https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com=America%2FLos_Angeles
>>
>

Re: [PROPOSAL] Preparing for Beam 2.12.0 release

[Ahmet Altay]

Sounds great, thank you!

On Wed, Mar 13, 2019 at 12:09 PM Andrew Pilloud  wrote:

> Hello Beam community!
>
> Beam 2.12 release branch cut date is March 27th according to the release
> calendar [1]. I would like to volunteer myself to do this release. I intend
> to cut the branch as planned on March 27th and cherrypick fixes if needed.
>
> If you have releasing blocking issues for 2.12 please mark their "Fix
> Version" as 2.12.0. Kenn created a 2.13.0 release in JIRA in case you
> would like to move any non-blocking issues to that version.
>
> Does this sound reasonable?
>
> Andrew
>
> [1]
> https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com=America%2FLos_Angeles
>

[PROPOSAL] Preparing for Beam 2.12.0 release

[Andrew Pilloud]

Hello Beam community!

Beam 2.12 release branch cut date is March 27th according to the release
calendar [1]. I would like to volunteer myself to do this release. I intend
to cut the branch as planned on March 27th and cherrypick fixes if needed.

If you have releasing blocking issues for 2.12 please mark their "Fix
Version" as 2.12.0. Kenn created a 2.13.0 release in JIRA in case you would
like to move any non-blocking issues to that version.

Does this sound reasonable?

Andrew

[1]
https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com=America%2FLos_Angeles