These are some valid concerns. But I don’t really see it that way after
thinking about it. We already have restrictions and consensus based
practices in place that may discourage new contributors. E.g. if someone
submits a patch to enable a different GC by default in 2.1, that’s
probably not going to happen, even if carefully tested by the
contributor. We also don’t accept any patches at all for older 3.x
versions, although there may be people who are not able to update to
3.11 and would really like to get their 3.x version patched for something.

That’s not because we want to discourage people from contributing in a
“scratch an itch” way. It’s just what we agreed on how to coordinate our
efforts and what kind of patches to accept for individual releases. So
if it’s fine to tell people that we’re not able to accept patches for
any version they are already running, why should we not be able to do so
for an upcoming, unreleased version that isn’t even used by anyone at
this point? Also, if we tell someone that their contribution will be
reviewed and committed later after 4.0-beta, how is that actually making
a difference for that person, compared to committing it now for a 4.x
version. It may be satisfying to get a patch committed, but what matters
more is when the code will actually be released and deferring committing
contributions after 4.0-beta doesn't necessarily mean that there's any
disadvantage when it comes to that.
On 12.07.18 15:23, Gary Dusbabek wrote:
---------------------------------------------------------------------
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB