Re: Policy for update third-party dependencies

2017-08-20 Thread 李玉珏
If the third party library is incompatible with the new version and the old version (such as lucene3.5.0-5.5.2), and the dependent version of Ignite is older, it may cause conflicts in the user's system. For such scenarios, I think that updating third-party dependencies's major version is valuab

[GitHub] ignite pull request #2489: ignite-5714-4

2017-08-20 Thread voipp
GitHub user voipp opened a pull request: https://github.com/apache/ignite/pull/2489 ignite-5714-4 You can merge this pull request into a Git repository by running: $ git pull https://github.com/voipp/ignite ignite-5714-4 Alternatively you can review and apply these changes as

Re: Policy for update third-party dependencies

2017-08-20 Thread Valentin Kulichenko
Guys, Keep in mind that some projects can use *older* version of third-party libraries as well, and dependency upgrade can break them. In other words, dependency upgrade is in many cases an incompatible change for us, so we should do this with care. Unless there is a specific reason to upgrade a

Re: Policy for update third-party dependencies

2017-08-20 Thread Nick Pordash
If the dependency is not exposed by the public API then another alternative is to simply shade the artifact and then this becomes a non-issue for users. Considering Ignite is a platform that executes user code via compute and service grid I personally think it would be good to minimize the number

[GitHub] ignite pull request #2453: Ignite 1.8.9 p2

2017-08-20 Thread mcherkasov
Github user mcherkasov closed the pull request at: https://github.com/apache/ignite/pull/2453 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is