-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release 7.0.0 #719
Release 7.0.0 #719
Conversation
FYI, I just rebased this and made sure it really contains all changes that are currently in master. We talked about this, and indeed: master is in a state we can use for a 7.0 release. The pressing changes are all merged. The unmerged stuff in the 7.0 milestone is optional. I would still love to merge as much as we can agree on, but we can take stuff out. Let's try to do a release on Tuesday or at least Wednesday. |
I rebased this again after #649 was merged. I also rearranged the 7.0.0 milestone an other time. No patch in this list should block the release, but it would still be sooo nice to have as much of them merged as possible. |
So what do I do to make a grammar fix now? If changes where submitted as dedicated PRs as soon as they are called for, I could just have merged the relevant stuff and made a follow up PR. Things go a lot faster like that if you ask me. |
RELEASE-NOTES.md
Outdated
## Version 7.0.0 (2017-03-07) | ||
|
||
This release allows `EntityIdValue` to support custom entity types, and needs to change snak, | ||
qualifier, and reference hashes because of this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This release adds support for custom entity types to EntityIdValue
, and thus to changes the hashes of snaks, qualifiers, and references.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe "thus to" was a mistake. Besides this is indeed better, and I used it. Thanks.
RELEASE-NOTES.md
Outdated
@@ -11,11 +27,12 @@ | |||
* Removed `HashArray::indicesAreUpToDate` | |||
* Removed `HashArray::removeDuplicates` | |||
* Removed `$acceptDuplicates` feature from `HashArray` | |||
* Added `clear` to `TermList`, `AliasGroupList` and `StatementList` | |||
* Fixed exceptions in `DispatchingEntityIdParser` and `ItemIdParser` not forwarding the previous | |||
exception |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please separate breaking changes from non-breaking changes as was done in the past
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
You can ask for changes just as you did, or amend this patch by using the edit button in the top right corner of each file. This will create a commit that will be part of this pull request. |
Asking for a change is slower, it takes more total effort, and is less collaborative IMO. Hence I prefer to make an actual proposal of this change. I could directly modify this PR as you suggest, though this leads to complications, esp when the author of the PR does not agree with the change (which did happen in the past and lead to hurt feelings). Anyway, this is just a general frustration I have with some PRs lately. It's not specific to this one, and I don't think it really matters for any single one, so no changes requested here from my side. |
What you are proposing is, from what I understand, that changes to master should be made faster, possibly even skipping review if the author feels like a change is not critical. In case somebody disagrees he can make a pull request any time. I believe I missed a point or just misunderstood that, but if this is the proposal I need to point out a problem: This creates the situation where one dev (or a small group) will make changes to a code base with almost no discussion (mostly because there is no time and no chance to react), while other devs that disagree are enforced to propose reverts or renames as pull requests that can only be merged when everybody agrees. While this discussion is ongoing master is already in a state that reflects the opinion of the first group. They basically "won", while the others must proof them "wrong". Personally I find this situation more frustrating than anything else. Commenting, or amending a patch, or chaining pull requests all avoid this situation. This is possible in both Gerrit and GitHub. |
@thiemowmde: it doesn't seem I am going to have few minutes to look at stuff you put into the 7.0.0 milestone any time soon. I don't think those changes are of high priority and we have more urgent stuff to do. That said how about we tag 7.0.0 with what we have now? If you say it's fine let's just change the date in the release notes, and I'll merge this and tag the release. |
Please have a look at the milestone before merging this: https://github.com/wmde/WikibaseDataModel/milestone/20
Bug: T157965