> On Mar 8, 2022, at 11:25 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > Answers inline below. FWIW, these are my opinions. I don’t know that the PMC > has ever made declarations to these.
I would like this thread to be the start of us as a project documenting what expectations we want folks to have. Does that sound reasonable? > >> On Mar 8, 2022, at 8:34 AM, Sean Busbey <sbus...@apple.com.INVALID> wrote: >> >> >> Hi folks! >> >> Apologies if I missed this discussion; I’ve read back through the dev list >> through 2021. I wanted to make sure I have the correct expectations before I >> start stomping around in Jira. >> >> I haven’t found a write up anywhere on what promises we make for >> major/minor/patch versions. What is the current expectation for: >> >> - compatibility of configs > > I tried to create a JSON version of the config. Unfortunately, the properties > syntax is not directly translatable as we allow both child properties and for > the property to have a value, which is not allowed in JSON and YAML. There > are a few other things I really don’t like about the config format. > But… I would never dream of breaking compatibility in a 1.x release. It would > even be tough doing it in 2.0 unless it isn’t too painful. > I would really love to integrate Flume with Spring Boot. That could mean the > Flume configuration could be in the application.yml. But that has issues. All > the Flume components use the config api and walk a properties tree. That > would still need to function. > > So my main point in this long-winded response is. Yes, I expect that configs > I currently have will continue to work in future releases. What version change would be needed to break configuration handling? It sounds like you’d prefer it be only on major version number changes? (I want to make sure we have consensus before I propose writing it down in the user guide.) > >> - compatibility of versions of things we can connect to (e.g. Kafka servers) > > There really isn’t much of a choice here. These 3rd party things make their > own rules. We don’t have much choice but to upgrade from time to time as the > older versions will be unsupported, which is a problem Flume currently faces > with many of its dependencies. We as a project could still increment our versions to indicate when we’ve dropped support for older third party offerings e.g. because they are no longer providing updated older versions of things. For example, if we drop support for talking to HDFS 2.x and require HDFS 3.x. I personally think it’d be better to convey that in a major version number, so that someone who is running an older HDFS and wants to upgrade Flume to deal with a CVE unrelated to HDFS could safely expect only a major version change from Flume would indicate they have something to worry about. > >> - compatibility of folks who implement our APIs to make their own components > > Every attempt should be made to keep APIs from breaking. Sounds good. I see we have InterfaceAudience and InterfaceStability annotations, similar to those provided by Apache Yetus Audience Annotations. Are the guidelines provided in the InterfaceStability annotation class[1] still accurate? * IA.Public/Stable - major version only * IA.Public/Evolving - minor version only * IA.Public/Unstable - can break in patch release > >> >> I know a big focus right now is on updating dependencies.Talking about >> expectations for the above ahead of time will help downstream users >> understand how difficult adopting those new dependencies will be from their >> perspective. >> >> Our last release was 1.9.0 in ~2019. The `trunk` branch currently has a >> SNAPSHOT version of 1.10.0. Right now JIRA has a combination of closed >> issues since 1.9.0 that say they are for version “2.0.0” and “1.10.0” and >> AFAICT the changes associated with them are all in the trunk branch. >> >> What is our next planned release version? What is the planned release after >> that? > > I am planning on the next release being 1.10.0. I haven’t given thought to > the release beyond that. I would only go to 2.0 if there is some significant > change to warrant it. > Does this mean some new feature that requires it? Or is updating our code base for maintainability in a way that causes a breaking change sufficient? For example, FLUME-2957 is flagged as a breaking change and as a result was already held out of the 1.9.0 release. >> >> If our next planned release is 1.10.0 and the release after that is 2.0.0, I >> think we should create a branch-1.10 now so that we have a place to triage >> which changes might need to be backed out depending on the above >> expectations for compatibility. >> >> If we’re not planning on a 2.0.0 this year, then we’ll need to review the >> already landed changes to make sure they’re in line with whatever >> expectations we want to set about compatibility. > > It is hard to say “we” and “planning” in the same sentence. Most of the > active Flume developers have gone on to other things, especially since > Cloudera no longer seems to use it, although Tristan has maintained an > interest in it. I use it for a critical component in my employers > infrastructure. So I have personal reasons for wanting to improve it. There > are a few other PMC members who still monitor Flume and will participate in a > release vote, but as far as planning goes my feeling is that we are free to > assume there are no concrete plans. > We’re an ASF project. Those of us who are participating here on the dev list are sufficient as a representation as the project planning in so far as any ASF project plans. I think from your prior messages your goal for the 1.10.0 release is the feature addition of configuration via URI(s) and to have whatever dependencies we can get updated. Is that correct? I think I won’t have an opinion on the timing of the release after 1.10.0 until we get through what the dependency updates look like. [1]: https://github.com/apache/flume/blob/release-1.8.0/flume-ng-core/src/main/java/org/apache/flume/annotations/InterfaceStability.java
