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 >> >> > >> >
