search

conversant / disruptor

Disruptor BlockingQueue
Apache License 2.0
311 stars 47 forks source link

enable Dependabot v2 #17

Closed sullis closed 2 years ago

sullis commented 4 years ago

https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/

Dependabot v2 can detect:

sullis commented 4 years ago

WDYT? @jac18281828

jac18281828 commented 4 years ago

Hi @sullis, In all honesty, I wasn't sure if this was an automated pull request or a real person so congratulations on passing the Turing Test. Also, I am aware that you are coming from a good place and want to improve the quality of code here and in other projects on GitHub so thank you! However, I don't feel like anywhere you have articulated what the goal is for this change, why it is needed or how this accomplishes it.

Personally, I'd like to understand better because this is a stable project with others using it and I don't see any need to make changes to it. In particular, untested changes or changes that are not motivated by fixing a real world issue seem ultimately more dangerous than beneficial in a project of this nature. Conversant Disruptor is very primitive code. It mainly uses the java.util.concurrency package and nothing else.

All of the maven packaging is simply for the purpose of building the distribution jars. Although I agree that our packaging is out of date. I question the reason to change it now. I have tested the existing code and personally deployed the jar to maven central using my signing key. How can I make the same certification if an automated process is updating things in a side channel.

I'm sure there are many types of projects where constant updating makes sense but for stable battle tested code it may be a losing proposition. What do you think? Also, as an aside, I'm open to a pull request that simply updates the offending packages.