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 <al...@google.com> 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 <k...@google.com> 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 <t...@apache.org> 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 <ieme...@gmail.com> 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 <adude3...@gmail.com> >>>> 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 <m...@apache.org> >>>> > 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 <al...@google.com >>>> >> > <mailto:al...@google.com>> wrote: >>>> >> > >>>> >> > Sounds great, thank you! >>>> >> > >>>> >> > On Wed, Mar 13, 2019 at 12:09 PM Andrew Pilloud >>>> >> > <apill...@google.com >>>> >> > <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&ctz=America%2FLos_Angeles >>>> >> >
