Skip to content
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

Staging of v1.1.0 #365

Merged
merged 51 commits into from
Jul 8, 2021
Merged

Staging of v1.1.0 #365

merged 51 commits into from
Jul 8, 2021

Conversation

ml-evs
Copy link
Member

@ml-evs ml-evs commented Jun 11, 2021

From discussion in #366 and at the workshop, it looks like the most reasonable option is to release v1.1.0 and skip v1.0.1. This PR stages those changes.

giovannipizzi and others added 30 commits July 1, 2020 17:50
This is also adds GitHub actions
The rest for now are still on Travis and can be moved at a later stage; in any case they require a different environment (java vs. python)
because they were intended to have trailing spaces to check the
syntax :-)

Excluding these two files explicitly now from the pre-commit
Co-authored-by: Casper Welzel Andersen <43357585+CasperWA@users.noreply.github.com>
…-space

Adding pre-commit tests (for trailing whitespaces)
* Updated schemas to the latest generated by optimade-python-tools v0.12.0

Co-authored-by: Casper Welzel Andersen <casper.andersen@epfl.ch>
* Added Java tests to GH actions
* Renamed GH actions file
* Added swagger validation using curl/jq and validator.swagger.io

* Restructured CI into multiple jobs

* Bump pre-commit version as suggested previously

* Disabled Travis
Co-authored-by: Casper Welzel Andersen <43357585+CasperWA@users.noreply.github.com>
Add field for implementation issue tracker
* Added Zenodo citation

* Update README.md

* Use HTTPS and link to unversioned DOI
)

* Sorted allowed word list for cleaner diff

* Added new audit tooling for spellchecking

* Fixed spelling mistakes in specification and updated .words.lst with 'make fix_spellings'
Co-authored-by: Casper Welzel Andersen <43357585+CasperWA@users.noreply.github.com>
Co-authored-by: Casper Welzel Andersen <43357585+CasperWA@users.noreply.github.com>
Redefine species.mass as a list of floats
…330)

* Updated schema to optimade-python-tools v0.12.9
* Update OpenAPI schemas for v0.13.0 of python-tools

* Bumped OPTIMADE spec version (1.0.1) and optimade-python-tools version (0.13.1)

* Use version number 1.0.1~develop

* Added regexp for prefix from v0.13.2 of python-tools

* Use 1.0.0~develop as the version tag
The related OPTIMADE Python tools PR:
Materials-Consortia/optimade-python-tools#731.
The changes are related to enumerations (Python Enum
sub-classes), extending information about them and defining
the default value for the aggregate field attribute for a links
resource.
JPBergsma and others added 4 commits July 7, 2021 15:06
… element names (#371)

* replaced name with symbol when refering to the abreviation of the element names.

* Update optimade.rst

Co-authored-by: Matthew Evans <7916000+ml-evs@users.noreply.github.com>

Co-authored-by: Johan Bergsma <johan.bergsma@gmx.com>
Co-authored-by: Matthew Evans <7916000+ml-evs@users.noreply.github.com>
* Add v1.1.0 schemas from optimade-python-tools v0.16.0

* Incorporate changes from #367
@ml-evs
Copy link
Member Author

ml-evs commented Jul 7, 2021

I have just bumped the version number in this PR (i.e. develop) to 1.1.0, so this is now ready for a final review and release.

@rartino: in the wiki release instructions, it talks about doing a -ff-only merge locally. I think this is equivalent to a GitHub PR rebase+merge, which I think is preferable...

optimade.rst Show resolved Hide resolved
@rartino
Copy link
Contributor

rartino commented Jul 7, 2021

@rartino: in the wiki release instructions, it talks about doing a -ff-only merge locally. I think this is equivalent to a GitHub PR rebase+merge, which I think is preferable...

I think the instructions were devised by @CasperWA originally, and were created before GitHub had these merge options. However, reading the documentation, I'm actually not sure that 'Rebase and merge' would be equivalent, because the documentation says the commit hashes will be updated, which we would like to avoid.

Copy link
Contributor

@rartino rartino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The v1.1.0 release looks ready to me.

@ml-evs
Copy link
Member Author

ml-evs commented Jul 7, 2021

I think the instructions were devised by @CasperWA originally, and were created before GitHub had these merge options. However, reading the documentation, I'm actually not sure that 'Rebase and merge' would be equivalent, because the documentation says the commit hashes will be updated, which we would like to avoid.

I'm 90% sure that GitHub will do a ff-only rebase when the history is linear (as it is here) but I will triple check in another repo. The GitHub docs do allude to this too. Let's see what @CasperWA says.

Copy link
Member

@merkys merkys left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@rartino
Copy link
Contributor

rartino commented Jul 8, 2021

I'm 90% sure that GitHub will do a ff-only rebase when the history is linear (as it is here) but I will triple check in another repo.

They indeed say that the merge is done fast-forward:

When you select the Rebase and merge option on a pull request on GitHub, all commits from the topic branch (or head branch) are added onto the base branch individually without a merge commit. Pull requests with rebased commits are merged using the fast-forward option. [...]

However, this other paragraph just below makes it sound as if that fast-forward is done using re-written (rebased) commits with different hashes:

The rebase and merge behavior on GitHub deviates slightly from git rebase. Rebase and merge on GitHub will always update the committer information and create new commit SHAs, whereas git rebase outside of GitHub does not change the committer information when the rebase happens on top of an ancestor commit.

@ml-evs
Copy link
Member Author

ml-evs commented Jul 8, 2021

Final steps:

  • I've written a little script to check all external links in the specification, we might consider adding this (or something similar) to the CI.
  • The release will need release notes: I think it makes sense to also add these to a top-level CHANGELOG.md in this repository (I believe this was discussed at one point, but not actioned upon). I will copy the notes from 1.0.0 and write new ones for 1.1 in a new PR, so we will need one more round of reviews for this.
  • Once this PR is approved again, I will locally merge the branch.

@ml-evs ml-evs marked this pull request as draft July 8, 2021 10:44
Copy link
Contributor

@JPBergsma JPBergsma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not see any major issues in this draft PR.
And great, that you made a script to test external links.

* Added a CHANGELOG containing release notes

* Add link to CHANGELOG in README

* Formatting

* Add clarifying word

* Apply suggestions from code review

Co-authored-by: Rickard Armiento <gitcommits@armiento.net>

* Placate pre-commit

Co-authored-by: Rickard Armiento <gitcommits@armiento.net>
@ml-evs ml-evs marked this pull request as ready for review July 8, 2021 15:07
@ml-evs
Copy link
Member Author

ml-evs commented Jul 8, 2021

Proceeding with the local merge... wish me luck!

@ml-evs
Copy link
Member Author

ml-evs commented Jul 8, 2021

🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority/high There is a consensus that resolving this should be prioritized.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants