Officially determine EOL (End of Life) of v0.10

[sonots]

We are yet supporting v0.10 (I am thinking so). Let's determine the date of EOL of v0.10.

Officially determining EOL of v0.10 makes saving time for plugin developer not to support v0.10 anymore.

[sonots]

ref. in the case of ruby, https://www.ruby-lang.org/en/news/2015/02/25/ruby-2-0-0-p643-is-released/

[mr-salty]

On a semi-related note, I have also found it painful to continue supporting ruby 1.9 in our plugin. I know 0.14 will not support ruby 1.9 but would you consider also dropping 1.9 support in 0.12?

[repeatedly]

would you consider also dropping 1.9 support in 0.12?

fluentd v0.12 doesn't drop ruby v1.9 support but each plugin can use different policy.
td-agent 2 uses ruby 2.1 and almost vanilla fluentd v0.12 users use ruby 2.1 or later.
ruby 1.9 and fluentd v0.12 pair seems toooooo rare.
So if newer plugins don't support ruby 1.9, I think it doesn't impact existing users.

[ppp0]

I'm a bit scared to read statements like:

On a semi-related note, I have also found it painful to continue supporting ruby 1.9 in our plugin. I know 0.14 will not support ruby 1.9 but would you consider also dropping 1.9 support in 0.12?
and
So if newer plugins don't support ruby 1.9, I think it doesn't impact existing users.

We are running a quite complex server farm (bare-metals and virtual) which runs quite a few Debian Wheezy nodes. This because of a lots of reasons and dependencies we're running on. Obviously, moving to Debian Jessie is our priority but this won't happen overnight (just think about what it means to move to a systemd-based service handler philosophy - and I'm not talking about e.g. mysql or php making a considerable version leap forward)

We recently started to use fluentd to centralize our loggin - and were so far very happy!

I am a bit disappointed to see how light-heartedly a whole group of users is cut off of using this tool. I understand the need you feel about phasing out versions of ruby that do not get the community's support anymore

My wish is that you move forward in consideration of existing users, that is, by enforcing a design that gracefully evolves rather than introduce disruptions. I think it should be needless to stress this for a tool like fluentd that aims to be a central part of a modern infrastructure.

Should this not be the case, I hardly see how this would become a tool of choice in a real-life system operation environment.

[tagomoris]

Ruby 1.9 is not maintained by ruby community. Of course, there are some Linux distributions which supports old ruby, but we cannot be responsible for problems brought by old ruby.
I think that we should make EOL ASAP for Fluentd v0.10, and ruby 1.9 even for Fluentd v0.12.

Thoughts?

[ppp0]

I agree that you do EOL but it would be nice if plugins would tag that, too, so that it's a user's responsibility to use to correct versions of both fluentd and plugins. Otherwise it makes fluentd unusable in real-life data centers. What hurts most is that everything was just working perfectly before!

[tagomoris]

I don't say that "we should introduce code which doesn't work ruby 1.9 intentionally".
What i'm saying that we should remove ruby 1.9 from our Travis CI configuration. It means that we don't keep our code to run on ruby 1.9. That's all, and I don't want to break any environment now running.

[ppp0]

Fully OK with that. I can easily say gem install fluentd --version '0.12.26' on Wheezy and it works fine. What breaks it are some of the plugins we're using who have fluentd as a dependency without any version contraints.. That's why I'm proposing https://github.com/ppp0/fluent-plugin-forest/blob/b2ec7efe49b05f3e2f258846295411c73e5d4fa4/fluent-plugin-forest.gemspec#L19

Otherwise, installing a plugin wants the latest version of fluentd - and this wrecks Wheezy installations

[mr-salty]

It's not just the plugins, though, it's everything the plugins depend upon. There are things out there without any required_ruby_version that nevertheless don't work anymore with ruby 1.9. Sometimes the breakage happens without a minor version bump on the plugin in question. So, you can write a plugin that works with 1.9, have required_ruby_version set properly, have all of your dependencies "correct", and still wake up one day to discover your plugin is now broken.

This is a subset of the general problem of dependency versioning, but it has become a fairly significant one, and it's what led to my comment, and dropping 1.9 support from the plugin I maintain.

[repeatedly]

I re-think this issue and I want to announce v0.10 EOL at the end of 2016.
Almost users are moved to td-agent 2 and newer users use v0.12 on production.
In addition, popular plugins work with v0.12 / v0.14.
In this year, we can release stable v0.14 so I think the end of 2016 is good.

How about this timeline?

[repeatedly]

There is no counter opinion from core developers.
I will announce v0.10 EOL in the mailing list.