On Fri, Oct 5, 2018 at 4:38 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> Hi, > > I think we have to remember what it's a LTS. A LTS is clearly a branch > that we guarantee to have fixes on it for a long period of time. > It doesn't mean that LTS == unique release. We can do a bunch of > releases on a LTS branch, the only constraint is to avoid to introduce > breaking changes. > I agree with this perspective. Thank you for sharing this. However the other commenters also had a good point. Requiring users to upgrade their runner version maybe incompatible with the goals of an LTS branch. Ideally the fixes here should be very minimal and targeted. > > So, IMHO, the key part is not release, it's branch. > > The first thing to decide is the branch. > > Instead of talking about 2.8.0 or 2.9.0, I would prepare a 2.8.x LTS > branch. It's a branch where we will cherry-pick some important fixes in > the future and where we will cut release. It's the approach I use in > other Apache projects (especially Karaf) and it works fine. > JB, does Karaf has a documented process that we can re-use? If not could you explain a bit more? Is the proposal here to prepare 2.8.x LTS branch and make a 2.8.0 release out of that? > > Just my $0.01 > > Regards > JB > > On 05/10/2018 12:14, Robert Bradshaw wrote: > > On Fri, Oct 5, 2018 at 3:59 AM Chamikara Jayalath <chamik...@google.com > > <mailto:chamik...@google.com>> wrote: > > > > > > On Thu, Oct 4, 2018 at 9:39 AM Ahmet Altay <al...@google.com > > <mailto:al...@google.com>> wrote: > > > > I agree that LTS releases require more thought. Thank you for > > raising these questions. What other open questions do we have > > related LTS releases? > > > > One way to do this would be to add them to a particular tracking > > list (e.g. 2.9.0 blocking list) that way we would be ready for > > an LTS release ahead of time. > > > > Related to dependencies, I agree with Thomas. If we block on > > waiting for dependencies, we may end up taking a long time > > before making any LTS release. And the reality of Beam releases > > right now is that there are no supported releases today that and > > in the long term that might hurt user trust. In my opinion, we > > need to fix that sooner rather than later. > > > > > > Agree on the idea of focussing on stability instead of feature set > > when it comes to LTS releases. Based on the previous discussion on > > this [1] looks like the intended audience is enterprise customers > > that would like to maintain a stable environment and that usually > > have a long testing cycle before deploying a new version. Seems > > like, rushing in features or dependency upgrades for an LTS release > > will be counterintuitive for such use cases. > > > > On the other hand, I think a part of Ismaël point was that all major > > features of Beam (Spark Runner, Flink Runner, Kafka IO, etc ..) > > should be supportable for the duration of the time Beam LTS release > > is supported (1 year based on [1]). If a major dependency is > > expected to become unsupported within an year, it makes sense to > > upgrade that before the LTS release. I suggest we do this at least > > one release before the planned LTS release (so 2.9.0 if we want to > > make 2.10.0 a LTS release) so that we have all major > > dependency/feature updates battle tested before committing to them. > > > > > > Dependencies are a significant concern. What happens if one of our > > dependencies has no version they're going to support for a year hence? > > It could happen that there's never a time when all our dependencies will > > be supported for at least a year as of any given date. And rushing to > > get the "latest" version of a dependency in is often contrary to the > > goals of an LTS. (Better to have those depend on the battle-hardened > > versions.) > > > > The long-term goal is probably to avoid pinning specific versions as > > much as possible. E.g. if we worked with Flink 1.5 or 1.6 (whichever the > > user provided), and considered backporting support for 1.7 when it came > > out, we'd be in much better shape here. How feasible this is depends on > > how backwards-compatible the dependency is. > > > > On the other hand, forcing a user to upgrade a (user-visible, which in > > particular includes runners) dependency seems contrary to the goals of > > an LTS. Even if that dependency becomes unsupported. > > > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
