-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I maintain a batterie of libraries for my company. Managing dependencies is one of the hardest part even with internal only libraries. Our major pain-point is the dependency towards 3rd party software and dealing with semver. Semver is not really hard to understand it’s just hard to execute as the developer is executing the rules. So for instance if I create a library/plugin etc which wraps around the a tool, would it be a breaking change when the software stops supporting a specific version of the wrapped tool even though the internal API stayed the same (this happens a lot for me with gradle plugins which suddenly decide to not being compatible with the version of gradle I use). I would say yes but for larger dependency trees this becomes a nightmare. For our internal unity3d libraries we decided to not count the supported Unity versions as part of the semver version. The other option would be to have special library packages for each version of unity similar to how the Spock testing framework[1] deals with groovy. For this option we don’t have enough engineers at my company.
[1] https://github.com/spockframework/spock