Release 0.3.0 to main #121

AntonReinhard · 2024-09-12T13:40:23Z

Release the new features to main in a new release process.

This is a release to main, do not squash or rebase

Merge release back into dev, main merge was in QEDjl-project#99

…project#106) Adds the functions `incoming_spin_pol`, `outgoing_spin_pol`, and `spin_pol` to the `AbstractProcessDefinition` interface. These can be implemented by specific processes, or rely on the provided default implementation which returns `AllSpin` or `AllPol` for each particle. Closes QEDjl-project#105

Adds a second directory for all implementations on the abstract interfaces. Type implementations go into QEDcore. Since I plan to add some more functionality on the AbstractProcessDefinition, this seemed necessary to keep structure. Also deletes a left-over duplicate file

Rewrite momenta function without broadcast, because GPUs do not like broadcasts in their kernels. This is essentially ported from QEDjl-project/QEDprocesses.jl#69 since this implementation moved here since that PR was opened.

) Fixes QEDjl-project#109

…et branch is not main (QEDjl-project#115) Copy of: QEDjl-project/QEDprocesses.jl#95

Fix CI branch names so `main` deploys docs as well.

…EDjl-project#118) As the title says, this adds an iterator to yield all possible combinations of spins and polarizations allowed by a process' set `spin_pols()`. For example: ```Julia julia> using QEDbase; using QEDcore; using QEDprocesses; julia> proc = ScatteringProcess((Photon(), Photon(), Photon(), Electron()), (Photon(), Electron()), (SyncedPolarization(1), SyncedPolarization(2), SyncedPolarization(1), SpinUp()), (SyncedPolarization(2), AllSpin())) generic QED process incoming: photon (synced polarization 1), photon (synced polarization 2), photon (synced polarization 1), electron (spin up) outgoing: photon (synced polarization 2), electron (all spins) julia> for sp_combo in spin_pols_iter(proc) println(sp_combo) end ((x-polarized, x-polarized, x-polarized, spin up), (x-polarized, spin up)) ((y-polarized, x-polarized, y-polarized, spin up), (x-polarized, spin up)) ((x-polarized, y-polarized, x-polarized, spin up), (y-polarized, spin up)) ((y-polarized, y-polarized, y-polarized, spin up), (y-polarized, spin up)) ((x-polarized, x-polarized, x-polarized, spin up), (x-polarized, spin down)) ((y-polarized, x-polarized, y-polarized, spin up), (x-polarized, spin down)) ((x-polarized, y-polarized, x-polarized, spin up), (y-polarized, spin down)) ((y-polarized, y-polarized, y-polarized, spin up), (y-polarized, spin down)) julia> length(spin_pols_iter(proc)) 8 ``` The above is also a `jldoctest`. As a side-note I also added an alias of `SyncedPol` to `SyncedPolarization`. The code is not incredibly concise and also not incredibly fast, but for the reasonable cases that I tested `@benchmark` reports well under 1ms. Since I don't think this iterator would be the critical path of anything this should be fine. The only problem I could see is that due to everything using `Tuple`s in its arguments, the compile time is relatively large. If this becomes a problem we could change it to using `Vector`s instead, likely trading some runtime for much better compile time. Fixes QEDjl-project#107

AntonReinhard · 2024-09-12T13:58:39Z

The doc building job fails because it's not setting the dev dependencies of the QEDproject packages, see the if condition:

      - name: set dependencies to dev branch version
        if: (github.event_name == 'push' && github.ref_name != 'main') || (github.event_name == 'pull_request' && github.base_ref != 'main')

I don't think this is intentional as we should always build the docs against the dev versions or they will fail in cases like this one, where breaking changes are introduced that cannot be released in the downstream packages yet.
@SimeonEhrig should I just delete the github.ref_name != 'main' conditions?

szabo137

There are several broken integration tests. It seems to be a compatibility problem. I suggest to update the packages depending on QEDbase.jl first, by replacing the pinned [compat] entry with a lower bound, e.g. "^0.2". After that, the integration tests in this PR should pass, and we can proceed with the release process.

AntonReinhard · 2024-09-12T19:25:25Z

There are several broken integration tests. It seems to be a compatibility problem. I suggest to update the packages depending on QEDbase.jl first, by replacing the pinned [compat] entry with a lower bound, e.g. "^0.2". After that, the integration tests in this PR should pass, and we can proceed with the release process.

^ is already the default specifier according to https://pkgdocs.julialang.org/v1/compatibility/. In any case, the point of the compat is to specify which versions are compatible, and allowing "any version higher than x" goes against that, when there can be breaking changes in the future that would automatically be included.

The problem isn't really with the compat entries, they are as they should be, the problem is that we want to "override" the compat entries for the testing. I think the simplest solution might be to modify the Project.toml in the package that the integration test is being created for, by deleting the currently tested package's compat entry entirely, so the resolve can't refuse installing it.

szabo137 · 2024-09-12T21:04:37Z

^ is already the default specifier according to https://pkgdocs.julialang.org/v1/compatibility/. In any case, the point of the compat is to specify which versions are compatible, and allowing "any version higher than x" goes against that, when there can be breaking changes in the future that would automatically be included.

I see, you are right.

The problem isn't really with the compat entries, they are as they should be, the problem is that we want to "override" the compat entries for the testing. I think the simplest solution might be to modify the Project.toml in the package that the integration test is being created for, by deleting the currently tested package's compat entry entirely, so the resolve can't refuse installing it.

I understand the problem, and I think your suggested solution will work. However, I don't know if it is a good idea to directly change the Project.toml, even just for testing. Maybe this would be a good question for discourse 🤔

SimeonEhrig · 2024-09-16T07:50:38Z

@SimeonEhrig should I just delete the github.ref_name != 'main' conditions?

"The biggest problem of the software development - User!". You constantly breaks my assumptions about the CI. I didn't thought about the possibility, that the documentation could have different dependencies compare to the actual software. Therefore the check forces the same requirement, that the main branch version needs to work with released packages.

But I see the problem. If we force this also for the documentation the QED dependency graph becomes an unmanageable thing, where everything is more or less depend on everything. Therefore I think we can relax the requirements for the documentation. But this also means, our documentation documents feature in the release which are maybe not working yet because a dependent QED project was not released in the required version yet.

@szabo137 What do you think?

AntonReinhard · 2024-09-16T10:50:34Z

There are two separate problems here, one is the documentation build, the other are the integration tests.

For the docs building:

"The biggest problem of the software development - User!". You constantly breaks my assumptions about the CI. I didn't thought about the possibility, that the documentation could have different dependencies compare to the actual software. Therefore the check forces the same requirement, that the main branch version needs to work with released packages.

I think the problem is that the docs can have dependencies to packages that are otherwise downstream of the package itself, and therefore needs to be considered similar to the integration tests instead of the unit tests. This does mean, as you say, that there might be docs for a time that aren't reproducible with only released packages, at least until all required downstream packages are released again.
In any case, we now always build the integration tests with dev dependencies and have the release version integration tests only as information for the developer, so always building the docs with dev dependencies too is just streamlining it in my opinion. So simply deleting the github.ref_name != 'main' check I mentioned should be an easy fix here that also makes sense.

Now for the integration tests

I think this is the bigger problem because as I said, we somehow need to force the downstream packages to accept the specific version of the package that we give it, regardless of what the compat tells it to use. The ideal scenario would be if the Julia's package manager allowed some kind of flag to override the compat entry, but from a quick google I can't find anything like this. Maybe it would be possible to ~~steal~~ borrow some code from Julia's CompatHelper to find and change the compat entry manually when generating the integration tests.

SimeonEhrig · 2024-09-16T12:41:19Z

There are two separate problems here, one is the documentation build, the other are the integration tests.

For the docs building:

"The biggest problem of the software development - User!". You constantly breaks my assumptions about the CI. I didn't thought about the possibility, that the documentation could have different dependencies compare to the actual software. Therefore the check forces the same requirement, that the main branch version needs to work with released packages.

I think the problem is that the docs can have dependencies to packages that are otherwise downstream of the package itself, and therefore needs to be considered similar to the integration tests instead of the unit tests. This does mean, as you say, that there might be docs for a time that aren't reproducible with only released packages, at least until all required downstream packages are released again. In any case, we now always build the integration tests with dev dependencies and have the release version integration tests only as information for the developer, so always building the docs with dev dependencies too is just streamlining it in my opinion. So simply deleting the github.ref_name != 'main' check I mentioned should be an easy fix here that also makes sense.

Now for the integration tests

I think this is the bigger problem because as I said, we somehow need to force the downstream packages to accept the specific version of the package that we give it, regardless of what the compat tells it to use. The ideal scenario would be if the Julia's package manager allowed some kind of flag to override the compat entry, but from a quick google I can't find anything like this. Maybe it would be possible to ~~steal~~ borrow some code from Julia's CompatHelper to find and change the compat entry manually when generating the integration tests.

Well, the integration tests clones the source code of the project to test. The Project.toml is just a toml file. Therefore there is nor reason why we cannot modify the file before we instantiate the project.

AntonReinhard · 2024-09-18T08:47:52Z

It looks like we have the same compat problem in the documentation too...

SimeonEhrig · 2024-09-18T11:46:29Z

It looks like we have the same compat problem in the documentation too...

I think this is something what we should discuss tomorrow. I was also thinking if the correct solution is to modify the compat entries of the packages on the dev branch version.

I already set up the deploy key and the private ssh key as a repository secret.

) Co-authored-by: Uwe Hernandez Acosta <[email protected]>

Following the suggestion made here: QEDjl-project/QEDcore.jl#45 (comment) --------- Co-authored-by: Uwe Hernandez Acosta <[email protected]> Co-authored-by: Anton Reinhard <[email protected]>

- [x] Fix jldoctests - [x] finish API reference - [x] Write tutorial for PSP - [x] Write tutorial for stateful particles - [x] Write tutorial for Lorentz vectors - [x] Write tutorial for particle interface - [x] Write tutorial for processes --------- Co-authored-by: Uwe Hernandez Acosta <[email protected]>

…project#125) Use overworked CI script to setup dev branch Julia environment. The CI scripts allows to resolve circular dependencies and modify compat entries of dependencies, if own project version was updated.

AntonReinhard · 2024-10-23T22:11:33Z

I will have to update the Changelog again, other than that this should (finally) be ready to merge

SimeonEhrig · 2024-10-24T07:07:42Z

@AntonReinhard The CI passed 🥳

szabo137 · 2024-10-24T07:21:00Z

@SimeonEhrig @AntonReinhard many thanks for you effort making this running (again) 🥳

szabo137

LGFM ✌️

AntonReinhard and others added 10 commits July 12, 2024 15:24

Release 0.2.2 (QEDjl-project#101)

108a270

Merge release back into dev, main merge was in QEDjl-project#99

Remove mul from exported functions and rename to _mul (QEDjl-project#110

d36c735

) Fixes QEDjl-project#109

Add Synced Spins and Polarizations (QEDjl-project#112)

60725f6

CI: set QED dependencies for doc build to dev branch version, if targ…

f3f1695

…et branch is not main (QEDjl-project#115) Copy of: QEDjl-project/QEDprocesses.jl#95

Fix CI docs building (QEDjl-project#116)

c544490

Fix CI branch names so `main` deploys docs as well.

QED project rename (QEDjl-project#120)

6251034

AntonReinhard requested a review from szabo137 September 12, 2024 13:40

szabo137 reviewed Sep 12, 2024

View reviewed changes

remove custom registry from the CI (QEDjl-project#123)

c92b587

AntonReinhard force-pushed the release-0.3.0 branch from d1f3a90 to a8675e5 Compare September 18, 2024 16:32

Add tagbot (QEDjl-project#124)

0fdfc6b

I already set up the deploy key and the private ssh key as a repository secret.

SimeonEhrig mentioned this pull request Sep 23, 2024

[DO NOT MERGE] test CI Bootloader #126

Draft

szabo137 and others added 3 commits October 9, 2024 17:36

dropped Julia <1.10 in CI, bumped combat to Juila1.10 (QEDjl-project#130

c4eeaa7

) Co-authored-by: Uwe Hernandez Acosta <[email protected]>

added coord trafo interface (QEDjl-project#129)

566e001

Following the suggestion made here: QEDjl-project/QEDcore.jl#45 (comment) --------- Co-authored-by: Uwe Hernandez Acosta <[email protected]> Co-authored-by: Anton Reinhard <[email protected]>

AntonReinhard force-pushed the release-0.3.0 branch from a8675e5 to 5725314 Compare October 21, 2024 14:25

SimeonEhrig and others added 2 commits October 23, 2024 23:05

CI: modify compat entries in docs build and integration tests (QEDjl-…

0e6d30c

…project#125) Use overworked CI script to setup dev branch Julia environment. The CI scripts allows to resolve circular dependencies and modify compat entries of dependencies, if own project version was updated.

Update version to 0.3.0

8904c78

AntonReinhard force-pushed the release-0.3.0 branch from 5725314 to bc8153b Compare October 23, 2024 21:07

AntonReinhard marked this pull request as draft October 23, 2024 22:10

Append 0.3.0 changelog

10aff71

AntonReinhard force-pushed the release-0.3.0 branch from bc8153b to 10aff71 Compare October 24, 2024 07:16

AntonReinhard marked this pull request as ready for review October 24, 2024 07:17

AntonReinhard requested a review from szabo137 October 24, 2024 07:20

szabo137 approved these changes Oct 24, 2024

View reviewed changes

AntonReinhard merged commit 4c0ec58 into QEDjl-project:main Oct 24, 2024
4 checks passed

AntonReinhard deleted the release-0.3.0 branch October 24, 2024 09:00

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Release 0.3.0 to main #121

Release 0.3.0 to main #121

AntonReinhard commented Sep 12, 2024

AntonReinhard commented Sep 12, 2024

szabo137 left a comment

AntonReinhard commented Sep 12, 2024

szabo137 commented Sep 12, 2024

SimeonEhrig commented Sep 16, 2024

AntonReinhard commented Sep 16, 2024

SimeonEhrig commented Sep 16, 2024

For the docs building:

Now for the integration tests

AntonReinhard commented Sep 18, 2024

SimeonEhrig commented Sep 18, 2024

AntonReinhard commented Oct 23, 2024

SimeonEhrig commented Oct 24, 2024

szabo137 commented Oct 24, 2024

szabo137 left a comment

Release 0.3.0 to main #121

Release 0.3.0 to main #121

Conversation

AntonReinhard commented Sep 12, 2024

AntonReinhard commented Sep 12, 2024

szabo137 left a comment

Choose a reason for hiding this comment

AntonReinhard commented Sep 12, 2024

szabo137 commented Sep 12, 2024

SimeonEhrig commented Sep 16, 2024

AntonReinhard commented Sep 16, 2024

For the docs building:

Now for the integration tests

SimeonEhrig commented Sep 16, 2024

For the docs building:

Now for the integration tests

AntonReinhard commented Sep 18, 2024

SimeonEhrig commented Sep 18, 2024

AntonReinhard commented Oct 23, 2024

SimeonEhrig commented Oct 24, 2024

szabo137 commented Oct 24, 2024

szabo137 left a comment

Choose a reason for hiding this comment