bitemyapp/bloodhound

Re-unifying Bloodhound's implementation

bitemyapp opened this issue · 4 comments

bitemyapp commented

We have no maintainers with an interest in maintaining a legacy version of Elasticsearch. I think it makes sense to go back to an un-versioned module namespace with a single implementation of the API.

  • The initial phase of this will be simply dropping the 1.x modules and removing the V5 part of the V5 implementation's namespace.

  • The next step from there will be targeting whatever the current, most recent release of Elasticsearch is and implementing support for that.

Some notes:

  • Anyone on an older version of Elasticsearch will need to use an older version of Bloodhound.

  • Elastic's EOL timeline is very aggressive, I don't have any reason or incentive to try to support ES versions they aren't bothering to support either. 5.x went EOL in March 2019 I believe. Cf. https://www.elastic.co/support/eol

  • This means we'll be skipping 6.x to go directly to 7.x.

If you have objections or suggestions, please offer this in this thread. I've been very brief here and I'd like to hear from users about this.

andrewthad commented

I'm only using Elasticsearch 7.x right now. I'm in favor of this plan.

MichaelXavier commented

Take my input with a grain of salt because I'm not currently actively using ES at the moment.

I think this idea makes sense. The current system has some disadvantages:

  • I suspect folks might be more hesitant to contribute even if it is a soft suggestion that they have to port their changes into other version branches that they might not be able to easily test.
  • It multiplies the amount of work that needs to be done to patch issues.
  • The test matrix is huge at this point and will only get bigger.
  • Compile times presumably would improve if you didn't have to compile for multiple versions.

So I think using ES' EOL as a deadline for upgrading bloodhound makes sense and if you can get it out faster than that, all the better. If folks want to maintain old versions they'll need to fork. If they want to maintain that effort for an extended period of time, they could potentially release it as a package of its own and be responsible for backporting as needed.

IMO it would be a good idea to be less aggressive about dependency upper bounds or just saw the dang things off except maybe in cases where you're pretty sure major changes are going to silently cause problems (past behavior, the nature of the library, etc). I suspect folks on older ES will be able to continue on using older versions of bloodhound and most of the time except for cases where dependencies move out ahead of it and the pessimistic bounds are protecting against a non-issue. I think upper bound stewardship ends up mostly being a waste of everyone's time.

bitemyapp commented

IMO it would be a good idea to be less aggressive about dependency upper bounds or just saw the dang things off except maybe in cases where you're pretty sure major changes are going to silently cause problems (past behavior, the nature of the library, etc).
[..] I think upper bound stewardship ends up mostly being a waste of everyone's time.

I agree. Thank you for offering your thoughts. You've done more work on Bloodhound than I have the last few years and I really appreciate the time you've put in. You've been a much more careful and thoughtful maintainer than myself. I'd certainly welcome your contributions to this or any other project I'm working on!

  • ❤️1
bitemyapp commented

I think this is done in master.