[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What is required for LTS releases? (was: [PROPOSAL] Prepare Beam 2.8.0 release)

I've seen two mentions that "rushing" is contrary to the goals of LTS. But I wouldn't worry about this. The fact is there is almost nothing you can do to stabilize *prior* to cutting the LTS branch. Stability comes from the branch being long-lived and having multiple releases.

(I think this is pretty much my version of what JB is saying)

What a conservative user will do if 2.8.x is declared LTS is to start using the 2.8.x branch after it has had a couple bugfix releases. I don't think it is useful or possible to try for an "extra stable" 2.x.0.

The arguments about supporting the most widely used versions of runner backends apply regardless of LTS. We should support them if we have the resources to do so.


On Tue, Oct 9, 2018 at 4:57 PM Ahmet Altay <altay@xxxxxxxxxx> wrote:

On Fri, Oct 5, 2018 at 4:38 AM, Jean-Baptiste Onofré <jb@xxxxxxxxxxxx> wrote:

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


On 05/10/2018 12:14, Robert Bradshaw wrote:
> On Fri, Oct 5, 2018 at 3:59 AM Chamikara Jayalath <chamikara@xxxxxxxxxx
> <mailto:chamikara@xxxxxxxxxx>> wrote:
>     On Thu, Oct 4, 2018 at 9:39 AM Ahmet Altay <altay@xxxxxxxxxx
>     <mailto:altay@xxxxxxxxxx>> 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.