New python and Matlab releases

[lfarv]

It's more than time to issue new releases of AT and PyAT.

For this, we should look at pending pull requests:

3 are waiting approval:

• Response matrices #893
• RDT observables #909
• Setting the nominal frequency on 6d lattices #923

It would be nice to get approval for these

2 are "active" drafts:

• Implementation of a new function to rotate an element #921
• Improved matching #892

Should we wait for these or postpone them to the next release?

3 are currently asleep:

• Update beamloading #906
• add crab cavity passmethod #899
• Add dp to rdts #890

[lcarver]

I will finish off the beam loading branch to try and get it merged (but i have easter holidays coming soon so will try to get it done before then).

[swhite2401]

@lfarv, I will free some time to review the pending PRs

• Setting the nominal frequency on 6d lattices #923 and RDT observables #909 are fine for me but I want to run some tests to make sure.
• Response matrices #893 is an improvement but would require additional features in my opinion to be really useful. This is nevertheless non blocking and it could be ok to merge as is it and improve later.

Concerning the active drafts:

• I have been using the matching extensively and we can merge that version, I am not excluding further suggestions. On e question though, where do we stand with this parameters class, I am now running into a case where I have to create a lot of observables to match a lattice which is rather painful.... the parameters class that was proposed at some point would be extremely useful.
• For the rotate element function I have no strong opinion, up to you.

Finally for stale branches, I think they either need more discussion or significant development, no need to rush on these.

[SebastienJoly]

For the element rotation branch, I think it does not require a lot of work before being ready. I will try to finish it as soon as possible.

[lfarv]

About versioning for this new release:

Should we switch to the new matching method: if so, we should change the major version number to report some changes breaking the compatibility. Therefore the python version would be 1.0.0. This also needs some reorganisation of modules, moving the old matching to a "deprecated" module (not imported by default), and moving the new matching into standard.

Otherwise, we can postpone the new matching to the next release and keep the version number at 0.7.0.

I would push for jumping to 1.0.0.

[swhite2401]

@lfarv, can we keep the new matching for future release? I think I am the only one that did the transition. At least let's first check with @simoneliuzzo if this is ok

[lfarv]

can we keep the new matching for future release

Ok, no problem. I'll add a word on that in the release notes.

[lfarv]

@swhite2401

where do we stand with this parameters class

I'll start again on that, and try the idea you proposed here.

[lfarv]

can we keep the new matching for future release?

Concerning the matching:

• we keep the old one by default, but
• I added a line in the release notes stating that the present matching will be deprecated in a future release, and suggesting to switch from now on to the new one.
• I added a line in the documentation of at/matching/matching.py (old one) saying that it is now obsolete, with links to the new variables, observables and matching,
• I added an example notebook showing the use of the new matching. The example is taken from the test modules, it's not optimum. A better example is welcome!

All this can be checked here. It should help the transition.

[lfarv]

@swhite2401, @SebastienJoly, @oscarxblanco, @simoneliuzzo
I think that we are now ready for new releases of AT and PyAT. Unless you suggest another modification… Please have a look at the release notes and decide.

[oscarxblanco]

@lfarv I think this is OK to release.

[SebastienJoly]

@lfarv Good for me as well