Answers inline below. FWIW, these are my opinions. I don’t know that the PMC has ever made declarations to these.
> 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. > - 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. > - compatibility of folks who implement our APIs to make their own components Every attempt should be made to keep APIs from breaking. > - removal of capabilities That depends. Removal of some specific component due to it no longer being supported with no replacement - absolutely OK. Removal of something like an interceptor interface, not so much. > > 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. > > 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. Ralph
