Feature/forward version to 6.0.0-alpha

[white-gecko]

Replace #1284

Proposed Changes

• Update the version string to allow installations from the git repo and let pip know, it is newer than the pypi release
• Will allow install with pip install git+https://github.com/rdflib/rdflib@master over a pypi installation

[white-gecko]

Does not do the trick. I don't know, where drone is cloning from.

[coveralls]

Coverage remained the same at 75.523% when pulling 3327193 on white-gecko:feature/forwardVersionTo6alpha into 65263ec on RDFLib:master.

[coveralls]

Coverage remained the same at 75.523% when pulling 3327193 on white-gecko:feature/forwardVersionTo6alpha into 65263ec on RDFLib:master.

[coveralls]

Coverage remained the same at 75.523% when pulling 3327193 on white-gecko:feature/forwardVersionTo6alpha into 65263ec on RDFLib:master.

[coveralls]

Coverage remained the same at 75.523% when pulling 3327193 on white-gecko:feature/forwardVersionTo6alpha into 65263ec on RDFLib:master.

[coveralls]

Coverage remained the same at 75.523% when pulling 3327193 on white-gecko:feature/forwardVersionTo6alpha into 65263ec on RDFLib:master.

[coveralls]

Coverage remained the same at 75.523% when pulling 3327193 on white-gecko:feature/forwardVersionTo6alpha into 65263ec on RDFLib:master.

[white-gecko]

@ashleysommer do you have any idea, where this behavior is coming from?

[ashleysommer]

Looks like Drone is trying to clone branch: feature/forwardVersion
But your branch is white-gecko:feature/forwardVersionTo6alpha
Did you rename your branch or something like that?

[ashleysommer]

Oh. No I'm wrong, this is weird.
Here is the test for this PR: https://drone.rdflib.ashs.dev/RDFLib/rdflib/66
It is cloning branch: feature/forwardVersionTo6alpha and it succeeded, and passed all tests.
But this github PR thread is still pointing to https://drone.rdflib.ashs.dev/RDFLib/rdflib/65 which is from the previous PR.

[ashleysommer]

Ok, I got an answer from one of the Drone maintainers.
Even though they're different branches, the HEAD commit SHA in the branch feature/forwardVersionTo6alpha is the same as the HEAD commit SHA in old branch feature/forwardVersion. So when github queries the CI status from Drone, it asks for the build for this commit SHA, but drone gives the status for the previous build, because it was the same commit SHA.

Note, that is why it appears that Drone doesn't restart its test when the PR is closed/re-opened, when actually it does. But the github status indicator will still point to the first build with that SHA.

[white-gecko]

:-) ok this is cool in a way, that there is some optimization towards the commit ID. I think this is good to know for possible future cases. Should I create a new commit with a new commit ID or do we want to merge it as it is?

[ashleysommer]

We'll commit as-is. I can already see it passes tests. thanks.