Fix sort on estimation for pruning

Same as #100 but for develop Also, brings some little changes done on master only in order to keep develop as up to date as master.

For the little story, I want to do that because this is how hotfixes should work. In the context of the GitHub flow (which we are trying to follow in this repo), a hotfix is something we do between 2 releases of the product to fix something really bad which can't wait for the next release to be fixed. This is one of the only cases where we are allowed to make a PR targeting master (because master is kind of the release branch we should never make PRs targeting master directly, except when releasing a version of the product, obviously). In our case, I already tagged the first version of Gomoku, the tag has been named following the semver rules which suggest we name release tag like this: vX.Y.Z with X for the major version, Y for the minor version and Z for the patches. So our first tag is called v1.0.0 since this is the very first tag. When every remaining bug will be addressed, we should then push a new tag named v1.0.1. All that to say, we are currently on the between of 2 release tag, so we need to make hotfixes from now on (so no more feature/ branches, only hotfix/ ones) and each of those hotfix branches should be used to create 2 different PRs, the first targeting master and the second one targeting develop. Doing so, we should be able to keep master and develop going forward at the same speed (same amount of commit in either branch). This is obviously not mandatory since we don't do actual releases of Gomoku, but it's never too early to start working with the industry standards right? 😉

abassibe / Gomoku

Fix sort on estimation for pruning #102