My primary objection is it burns a major version number for no good reason, provides no useful information, and is misleading.
1. The following release is going to be a major release as there will be significant changes to how flume is packaged and maintained. So we will have a 2.0 that changes nothing important followed by 3.0 that does. 2. A major version number implies user customizations likely need to be modified. That is not the case. 3. Anyone still using ES 0.90.1 almost certainly doesn’t care about the release. In the end, it sends the wrong message to users. Nothing significant changed as the ES support is unusable as it stands. Ralph > On Apr 1, 2022, at 12:42 AM, Bessenyei Balázs Donát <bes...@apache.org> wrote: > > >> >> Donat, I don’t want to do anything until I am sure we have consensus on how >> to proceed. Will you go along with removing ES from the 1.10.0 release? > > I don't mean to block any work here and I haven't found anywhere that > Flume follows semantic versioning. Still, I'd like to understand why > we can't make any next release 2.0. > > > Thank you, > Donat > > >> On Fri, Apr 1, 2022 at 9:02 AM Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >> >> >> >>>> On Mar 31, 2022, at 7:44 PM, Sean Busbey <sbus...@apple.com.INVALID> wrote: >>> >>>> At some point you have to drop the older versions that are no longer >>>> supported by the project they target. That typically does not warrant a >>>> major version update. >>> >>> FWIW I still agree we should drop the ES module, but in general we should >>> avoid changes that break what systems flume can talk without having a major >>> version change. In the future I’d strongly prefer we increment our major >>> version number as we drop these older modules. Hopefully once we have a >>> regular release cadence we can set some expectations about how often that >>> will be. >>> >> >> As I said previously, when we split things up in 2.0 I think this will >> become much less of a problem. Instead of increasing the major version >> number of Flume, providing a version compatible with something recent and >> removing the old version would have caused the major version number for >> flume-elasticsearch to increase. Ideally, the core components of Flume would >> only see a major version increase when there are significant changes to it, >> not to dependencies. >> >> Donat, I don’t want to do anything until I am sure we have consensus on how >> to proceed. Will you go along with removing ES from the 1.10.0 release? >> >> Ralph >>
