Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 58.48%. Comparing base (4f15ce5) to head (34a7f5f).

@@           Coverage Diff           @@
##           master    #1104   +/-   ##
=======================================
  Coverage   58.48%   58.48%           
=======================================
  Files         262      262           
  Lines       18198    18198           
=======================================
  Hits        10643    10643           
  Misses       7555     7555           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

LGTM. Maybe you want to call out the updated citation information/DOI in the main summary, to make academic users aware? Either way is fine by me.

LGTM. Maybe you want to call out the updated citation information/DOI in the main summary, to make academic users aware? Either way is fine by me.

Good idea, I added it.

Once we're about to release, the most recent PRs have to be incorporated.

@BenediktBurger should we do this release manually instead of waiting for the automatic workflow to be possible? #

IIUC, we should soon push another follow-up release (with updated dependency info) out after numpy 2.0 has been released, anyway (where we can test the automatic workflow)? Right, @CasperSchippers ?

Ok, if you can spare the time for a manual release, it's fine with me.

Note, that a few more PRs have been merged in the mean time.

I'd like to have #1110 merged as well (it's just reducing the time limit in a test to make it pass).

IIUC, we should soon push another follow-up release (with updated dependency info) out after numpy 2.0 has been released, anyway (where we can test the automatic workflow)? Right, @CasperSchippers ?

We should indeed, after numpy 2.0 is released, update the requirements file for the numpy 2 test. I think we don't need to do much else, so I'm not sure if (as long as all the tests keep on succeeding) that by itself warrants an additional release.

@bilderbuchi , are you fine with releasing?
In that case, I'll add the current date and start (and accept) a release.

The tests fail due to #1112

You wanted to pull in #1110, is that still the case?

I'd be quite wary of merging (and especially releasing!) with broken tests!

You wanted to pull in #1110, is that still the case?

I'd love to, but I need a reviewer...

I'd be quite wary of merging (and especially releasing!) with broken tests!

Let's diagnose the setuptools thing.

I bumped the requirement to 8.1.0 for setuptools_scm, but mamba loads 8.0.4.
That is probably the reason, why the error persists.

I deleted all the caches and restarted the failed checks.

EDIT: They still failed.

With the most recent setuptools_scm version (enforced via pymeasure.yml environment file), the tests pass.

@bilderbuchi , now we can release with the tests passing, I think (today's date is already present).

@bilderbuchi I created a release draft. Do you want to address #1112 with the setuptools_scm dependency first?
Feel free to release my draft and upload thus to Pypi.

Btw. I did uncheck the "latest release" on purpose, such that we can verify the pypi upload and check the "latest release" afterwards.

I just did!

Seems to have worked: https://pypi.org/project/PyMeasure/#history

Can you confirm this is all as it should be on your end?

Now we only need to merge this PR with rebase-and-merge (!) so that the tag ends up inline on the master branch, afaik GH just does a fast-forward merge if possible.
Can you do that on your end once you've completed a quick check?

Thank you! Minor hiccup: the tag https://github.com/pymeasure/pymeasure/releases/tag/v0.14.0 points to 34a7f5f, which is only on the PR branch (so will disappear once that goes away), so apparently this did rebase although fast-forward was possible -- the commit on master is 6573de5
:-(

Solutions? A local manual merge and subsequent push? First merging the PR then doing the deployment? Somehow convincing GH to merge fast-forward?

Yes, I noticed it, too and was thinking about solutions.

Would a normal merge have been better, as that would add the commit (with the tag) as is to the main tree, wouldn't it?
It would be the second to last commit after the merge commit.

Solution for now: Merge the v0.14.0_release branch into the master?

Would a normal merge have been better, as that would add the commit (with the tag) as is to the main tree, wouldn't it?
It would be the second to last commit after the merge commit.

Yes, that's probably the least painful option. We should document that we need to choose that merge method in the release process.

Solution for now: Merge the v0.14.0_release branch into the master?

yeah, although I suspect this could just be empty/a no-op. IDK what will happen, try locally first, please.

Solution for now: Merge the v0.14.0_release branch into the master?

yeah, although I suspect this could just be empty/a no-op. IDK what will happen, try locally first, please.

A local try was my plan: It succeeded. Shall I push it?

Now the tag is shown to be part of the master branch!

Thanks for your collaboration on this additional issue.

Sure, no problem!