On Wed, Oct 10, 2018 at 2:56 AM Robert Bradshaw <rober...@google.com> wrote:
> On Wed, Oct 10, 2018 at 9:37 AM Ismaël Mejía <ieme...@gmail.com> wrote: > >> The simplest thing we can do is just to pin all the deps of the LTS >> and not move them in any maintenance release if not a strong reason to >> do so. >> >> The next subject is to make maintainers aware of which release will be >> the LTS in advance so they decide what to do with the dependencies >> versions. In my previous mail I mentioned all the possible cases that >> can happen with dependencies and it is clear that one unified policy >> won’t satisfy every one. So better let the maintainers (who can also >> ask for user feedback in the ML) to decide about versions before the >> release. >> >> Alexey’s question is still a really important issue, and has been so >> far ignored. What happens with the ‘Experimental’ APIs in the LTS. >> Options are: >> >> (1) We keep consistent with Experimental which means that they are >> still not guarantees (note that this does not mean that they will be >> broken arbitrarily). >> (2) We are consistent with the LTS approach which makes them ‘non >> experimental’ for the LTS so we will guarantee the functionality/API >> stable. >> >> I personally have conflicted opinions I would like to favor (1) but >> this is not consistent with the whole idea of LTS so probably (2) is >> wiser. >> > > Yeah, I think (2) is the only viable option. > I think important thing here is that future releases on a LTS branch will be patch (bugfix) releases so I don't think we can/should do API/functionality changes (even if the change is experimental and/or backwards compatible). I think same goes for dependency changes. If the change is to fix a known bug we can do that in a patch release but if it's to add more functionality probably that should come in a new minor release instead of a patch release. This is why I think we should be bit careful about "rushed" changes to major functionalities of Beam going into LTS releases. Just my 2 cents. Thanks, Cham > > >> Finally I also worry about Tim’s remarks on performance and quality, >> even if some of these things effectively can be fixed in a subsequent >> LTS release. Users will probably prefer a LTS to start with Beam and >> if the performance/quality of the LTS, this can hurt perception of the >> project. >> > > Yes, for this reason I think it's important to consider what goes into an > LTS as well as what happens after. Almost by definition, using an LTS is > choosing stability over cutting edge features. I'd rather major feature X > goes in after LTS, and lives in a couple of releases gaining fixes and > improvements before being released as part of the next LTS, than quickly > making it into an LTS while brand new (both due to the time period before > we refine it, and the extra work of porting refinements back). > > Or maybe LTS-users are unlikely to pick up a x.y.0 release anyway, waiting > for at least x.y.1? > > Come to think of it, do we even have to designate releases at LTS at the > time of release? Perhaps we could instead just keep with our normal release > cadence, and periodically choose one of them as LTS once we've confirmed > its stability out in the wild and start backporting to it. (I can think of > several cons with this approach as well, e.g. generally it's easier to > backport bugfixes at the time a bugfix is done in master rather than > swapping in context at a later date, but just thought I'd throw it out > there.) > > On Wed, Oct 10, 2018 at 4:53 AM Kenneth Knowles <k...@apache.org> wrote: >> > >> > 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. >> > >> > Kenn >> > >> > On Tue, Oct 9, 2018 at 4:57 PM Ahmet Altay <al...@google.com> wrote: >> >> >> >> >> >> >> >> 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 >> >> >> >> >> >
