+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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>> 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 <[email protected] >>> >> > <mailto:[email protected]>> wrote: >>> >> > >>> >> > Sounds great, thank you! >>> >> > >>> >> > On Wed, Mar 13, 2019 at 12:09 PM Andrew Pilloud < >>> [email protected] >>> >> > <mailto:[email protected]>> 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 >>> >> > >>> >>
