Release v1.8

This is to track the work to be done for release v1.8

Migrate non-urgent issues/PRs to the 1.8.1 label (1.8.1 list)
Close out remaining PRs and issues (PRs, issues)
Create release-1.8 branch (branch)
Create a v1.8 tag for the release
Bump version, update changelog, docs and other files (Update changelog and bump version to v1.8 #1250, Update ANNOUNCE for v1.8 #1252, docs: update maintainers list and parsed program versions #1253)
Update release tag to HEAD on release branch
Create a draft release from the v1.8 tag
Attach source tar and zip archives to release on GitHub
When ready, publish the draft release (https://github.com/cclib/cclib/releases/tag/v1.8)
Upload new version to PyPI (https://pypi.org/project/cclib/1.8/)
Make sure conda picks up the change (cclib v1.8 conda-forge/cclib-feedstock#8)
Update Zenodo if a major or minor version (https://zenodo.org/record/8280878)
Make sure Zenodo parts of documentation get updated (Update Zenodo citations and links for 1.8 #1261)
Merge the release-1.8 branch back into master (Merge release 1.8 branch back into master #1265)
Send email to MLs

@shivupa

@shivupa Can you see if there is an Action that creates source distributions/wheels and automatically uploads them to PyPI when a tag is pushed? This isn't a blocker in any way but may make our lives a little easier in the future.

Update CHANGELOG and bump version: #1250

The order on https://cclib.github.io/development.html#releasing-a-new-version is different from here regarding when and where to make the tag. Looking at history,

1.7.2 is on release-1.7.2 just before merging back to master.
1.7.1 is slightly before even making the release-1.7.1 branch? Maybe it's at the branch point.
1.7 is slightly before even making the release-1.7 branch (same as 1.7.1).
1.6.4 is on release-1.6.4 but not the final commit before merge.
1.6.3 is on the merge commit for release-1.6.3.
1.6.2 is on the merge commit for release-1.6.2 (same as 1.6.3).
1.6.1 is on release-1.6.1 just before merging back to master (same as 1.7.2).
1.6 is on release-1.6 but not the final commit before merge (same as 1.6.4).

Updated ANNOUNCE except Zenodo DOI: #1252

Update maintainers list and parsed program versions in docs: #1253

There is a question in #1250 about whether or not to push the tag to the release-1.8 or the master branch. It looks like we have precedent for both. The answer I got online is that the tag should point to the commit that corresponds to the released code, and that would be the code that gets uploaded to PyPI, conda-forge, and Zenodo.

The released code could technically be either branch, at least once release-1.8 has been merged into master. But this makes an assumption, which is that master has not progressed past the base of release-1.8. This would happen if we merge features that we don't want to add to the release. At least by this logic, we should tag on release-1.8. And I think this is what the checklist says.

If I am missing something here, please tell me.

I don't see how "Update release tag to HEAD on release branch" is necessary if we wait to make the tag until the branch is done, like right now.

https://softwareengineering.stackexchange.com/q/165725/: gitflow doesn't quite apply because we use master as their develop.
https://softwareengineering.stackexchange.com/q/347525/: same comment about gitflow.
https://stackoverflow.com/q/20755434/: more comments about gitflow.
https://softwareengineering.stackexchange.com/q/442334/: the rebuttal here is that we have a dedicated release branch, not feature branch, which not only will never get deleted, but will get merged back in, so the individual commits don't disappear.
https://softwareengineering.stackexchange.com/q/131171/: it sounds like we are doing a combination of A and B.
https://softwareengineering.stackexchange.com/a/311286/: I think this answer describes almost exactly what we're doing.

Tag pushed to the merge commit of #1250.

The archives I created with python setup.py sdist --formats=gztar,zip are huge because they include data for some reason. Checking out the 1.7.2 tag and redoing this also makes big archives, so it isn't a change in our build infrastructure, it must be my setup. Can someone else try this?

There is a question in #1250 about whether or not to push the tag to the release-1.8 or the master branch. It looks like we have precedent for both. The answer I got online is that the tag should point to the commit that corresponds to the released code, and that would be the code that gets uploaded to PyPI, conda-forge, and Zenodo.

The released code could technically be either branch, at least once release-1.8 has been merged into master. But this makes an assumption, which is that master has not progressed past the base of release-1.8. This would happen if we merge features that we don't want to add to the release. At least by this logic, we should tag on release-1.8. And I think this is what the checklist says.

If I am missing something here, please tell me.

I don't see how "Update release tag to HEAD on release branch" is necessary if we wait to make the tag until the branch is done, like right now.

https://softwareengineering.stackexchange.com/q/165725/: gitflow doesn't quite apply because we use master as their develop.

https://softwareengineering.stackexchange.com/q/347525/: same comment about gitflow.

https://stackoverflow.com/q/20755434/: more comments about gitflow.

https://softwareengineering.stackexchange.com/q/442334/: the rebuttal here is that we have a dedicated release branch, not feature branch, which not only will never get deleted, but will get merged back in, so the individual commits don't disappear.

https://softwareengineering.stackexchange.com/q/131171/: it sounds like we are doing a combination of A and B.

https://softwareengineering.stackexchange.com/a/311286/: I think this answer describes almost exactly what we're doing.

Sounds good! I've wondered about best practice for this in the past as well. I think as long as the tag makes it to master eventually it's all good, doesn't matter that much if there's some commits that don't show up on the release branch.

@langner

Tag pushed to the merge commit of #1250.

The archives I created with python setup.py sdist --formats=gztar,zip are huge because they include data for some reason. Checking out the 1.7.2 tag and redoing this also makes big archives, so it isn't a change in our build infrastructure, it must be my setup. Can someone else try this?

poke @langner because I can't reproduce the release archives for any tag.

Tag pushed to the merge commit of #1250.

The archives I created with python setup.py sdist --formats=gztar,zip are huge because they include data for some reason. Checking out the 1.7.2 tag and redoing this also makes big archives, so it isn't a change in our build infrastructure, it must be my setup. Can someone else try this?

Not sure why they're so big... I was able to generate very small packages from a fresh clone -- see a draft release I created https://github.com/cclib/cclib/releases/tag/untagged-fd275c90e79204d3336f where I added them. Changing the wording in the checklist to make this clearer ("Publish a release from the release-1.8 branch" -> "Create a draft release from the 1.8 tag"). Separated out publishing the draft to a separate step.

How did you add your large assets? I can't figure out how to delete them now.

I ran python setup.py sdist --formats=gztar,zip on a fresh checkout.

dist_log.txt

I ran python setup.py sdist --formats=gztar,zip on a fresh checkout.

dist_log.txt

This is with my system Python, 3.11.3. Using 3.9.17 and 3.11.4 from pyenv don't have this problem. System 3.11 has setuptools 68.0.0 and pyenv has 65.5.0. Updating the pyenv install to 68.0.0 doesn't reproduce the problem. It's the setuptools-scm package in my system install. From https://github.com/pypa/setuptools_scm:

Additionally setuptools_scm provides setuptools with a list of files that are managed by the SCM (i.e. it automatically adds all of the SCM-managed files to the sdist). Unwanted files must be excluded by discarding them via MANIFEST.in.

I think "Make sure documentation gets updated" is from before the docs build was automated, but it can be repurposed to come after Zenodo and before merging the release branch back into master: update all the Zenodo/DOI references to the latest Zenodo version for minor (not patch) releases.

We need a fix for #1256. I discovered it when trying to install from TestPyPI. Even though we aren't uploaded to PyPI, we have a tag and (GitHub) release already. The release can be deleted and the tag can be force-pushed to the release branch once the patch is in, but I'm not sure that's the best thing to do. I do not want to do v1.8.post1 or whatever the syntax is.

My thought is that force-pushing the tag after #1259 is done is the same as force-pushing a branch a few other people are using: not ideal and a little painful for those people, but not the end of the world. If this were on PyPI it would be a different matter. People who install directly from GitHub and not PyPI and aren't packagers are early adopters. I bet re-packagers are pulling from PyPI, and even so, important ones (https://packages.debian.org/search?keywords=cclib&searchon=names&suite=all&section=all) may be far behind.

We will add #1249 (comment) or some sort of dist checking to the release process so this can't happen again.

#1259 works:

$ python -m pip install cclib
Collecting cclib
  Using cached cclib-1.7.2-py3-none-any.whl
Collecting packaging>=19.0 (from cclib)
  Using cached packaging-23.1-py3-none-any.whl (48 kB)
Collecting numpy (from cclib)
  Obtaining dependency information for numpy from https://files.pythonhosted.org/packages/32/6a/65dbc57a89078af9ff8bfcd4c0761a50172d90192eaeb1b6f56e5fbf1c3d/numpy-1.25.2-cp311-cp311-manylinux_2_17_x86_64.manylinux
2014_x86_64.whl.metadata
  Using cached numpy-1.25.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (5.6 kB)
Collecting periodictable (from cclib)
  Using cached periodictable-1.6.1-py2.py3-none-any.whl (752 kB)
Collecting scipy>=1.2.0 (from cclib)
  Obtaining dependency information for scipy>=1.2.0 from https://files.pythonhosted.org/packages/0e/a0/8606a7eef659f3d5f79d9efb92eed3ed1243178f4ae962614e1b202935a6/scipy-1.11.2-cp311-cp311-manylinux_2_17_x86_64.ma
nylinux2014_x86_64.whl.metadata
  Using cached scipy-1.11.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (59 kB)
Collecting pyparsing (from periodictable->cclib)
  Obtaining dependency information for pyparsing from https://files.pythonhosted.org/packages/39/92/8486ede85fcc088f1b3dba4ce92dd29d126fd96b0008ea213167940a2475/pyparsing-3.1.1-py3-none-any.whl.metadata
  Using cached pyparsing-3.1.1-py3-none-any.whl.metadata (5.1 kB)
Using cached scipy-1.11.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (36.3 MB)
Using cached numpy-1.25.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (18.2 MB)
Using cached pyparsing-3.1.1-py3-none-any.whl (103 kB)
Installing collected packages: pyparsing, packaging, numpy, scipy, periodictable, cclib
Successfully installed cclib-1.7.2 numpy-1.25.2 packaging-23.1 periodictable-1.6.1 pyparsing-3.1.1 scipy-1.11.2
$ python -m pip install -i https://test.pypi.org/simple/ --no-deps -U cclib
Looking in indexes: https://test.pypi.org/simple/
Requirement already satisfied: cclib in ./venv_11/lib/python3.11/site-packages (1.7.2)
Collecting cclib
  Obtaining dependency information for cclib from https://test-files.pythonhosted.org/packages/a9/c1/85f67842dde7ab084d3b365c0eaa69666ab40bf204710d254a7e3956240e/cclib-1.8.post1-py3-none-any.whl.metadata
  Downloading https://test-files.pythonhosted.org/packages/a9/c1/85f67842dde7ab084d3b365c0eaa69666ab40bf204710d254a7e3956240e/cclib-1.8.post1-py3-none-any.whl.metadata (1.2 kB)
Downloading https://test-files.pythonhosted.org/packages/a9/c1/85f67842dde7ab084d3b365c0eaa69666ab40bf204710d254a7e3956240e/cclib-1.8.post1-py3-none-any.whl (346 kB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 346.4/346.4 kB 5.8 MB/s eta 0:00:00
Installing collected packages: cclib
  Attempting uninstall: cclib
    Found existing installation: cclib 1.7.2
    Uninstalling cclib-1.7.2:
      Successfully uninstalled cclib-1.7.2
Successfully installed cclib-1.8.post1
$ python
Python 3.11.4 (main, Aug 20 2023, 23:53:53) [GCC 13.2.1 20230801] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cclib
>>> cclib.__version__
'1.8'

(I had to make a new tag for TestPyPI but should be able to use v1.8 for production PyPI.)

I've discovered that the top-level docstring is severely out-of-date for supported programs:

>>> help(cclib)
Help on package cclib:

NAME
    cclib - A library for parsing and interpreting results from computational chemistry packages.

DESCRIPTION
    The goals of cclib are centered around the reuse of data obtained from various
    computational chemistry programs and typically contained in output files. Specifically,
    cclib extracts (parses) data from the output files generated by multiple programs
    and provides a consistent interface to access them.

    Currently supported programs:
        ADF, Firefly, GAMESS(US), GAMESS-UK, Gaussian,
        Jaguar, Molpro, MOPAC, NWChem, ORCA, Psi, Q-Chem

    And additionally: formatted checkpoints files (fchk)

Rather than have burden of continually updating this list, I think we should restrict ourselves to just the one on the docs homepage and get rid of this one and any others that may be lurking.

@shivupa

I've started on the Zenodo submission. Reminder to myself to see if there is a Python API for this because filling out the entry is annoying.

Please send me or post your ORCID if you would like it included. (@shivupa @amandadumi @langner @oliver-s-lee @schneiderfelipe @ghutchis)

All the past archives in Zenodo are not the ones uploaded to PyPI or our releases, but the state of the entire repository at the tag, with .git removed.

@shivupa

I've started on the Zenodo submission. Reminder to myself to see if there is a Python API for this because filling out the entry is annoying.

Please send me or post your ORCID if you would like it included. (@shivupa @amandadumi @langner @oliver-s-lee @schneiderfelipe @ghutchis)

https://orcid.org/0000-0001-8090-2976

Thanks!

https://orcid.org/0000-0002-8501-0501

Thanks!

0000-0002-2693-8537

Thank you!

https://orcid.org/0009-0005-8365-816X

Cheers!

😪 🛌

Navigation Menu

Repository navigation

Release v1.8 #1249

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Release v1.8 #1249

Description

Activity

berquist commented on Aug 10, 2023

berquist commented on Aug 10, 2023

berquist commented on Aug 16, 2023

berquist commented on Aug 16, 2023

berquist commented on Aug 18, 2023

berquist commented on Aug 18, 2023

langner commented on Aug 20, 2023

berquist commented on Aug 20, 2023

langner commented on Aug 20, 2023

berquist commented on Aug 21, 2023

berquist commented on Aug 21, 2023

berquist commented on Aug 22, 2023

berquist commented on Aug 22, 2023

berquist commented on Aug 22, 2023

berquist commented on Aug 24, 2023

berquist commented on Aug 25, 2023

berquist commented on Aug 26, 2023

schneiderfelipe commented on Aug 27, 2023

shivupa commented on Aug 27, 2023

amandadumi commented on Aug 28, 2023

oliver-s-lee commented on Aug 28, 2023

berquist commented on Aug 28, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions