You are welcome. But I am still not clear where that leaves us. Is ES in or out 
of the 1.10.0 release?

Ralph

> On Apr 1, 2022, at 7:25 AM, Bessenyei Balázs Donát <bes...@apache.org> wrote:
> 
> +1.
> Thank you for the explanation!
> 
> 
> Donat
> 
> 
> On 2022. Apr 1., Fri at 16:21 Apache <ralph.go...@dslextreme.com> wrote:
> 
>> 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
>>>> 
>> 
>> 

Reply via email to