Cherab development branch is incompatible with Raysect development branch due to material API changes

[vsnever]

Since Raysect 0.7.1 is released, I think until the new version of Cherab is ready we should set ci.yml to build with Raysect master branch.

[jacklovell]

I think we should go further than this and always build against a released version of Raysect. This would allow us to more quickly push out new versions of Cherab with bug fixes or additional features without having to coordinate releases with Raysect or to put undue pressure on them to advance a release.

Any new Cherab features which require unreleased capabilities in Raysect (e.g. on the Raysect development branch) should in turn stay in their own feature branches in Cherab and only be merged into the development branch once the corresponding Raysect feature is released.

@CnlPepper @Mateasek @mattngc thoughts on this?

[Mateasek]

I'm not sure I understand correctly what you mean, so I'm sorry if my comment os off topic. For me the system in which the cherab development branch aimed to be working with the raysect development branch was efficient and I thought that anybody who couldn't work with git and python to match working versions was supposed to used pip and master branches. Having to merge several feature brances in order to work on a new one seems quite a pain.

[vsnever]

This makes sense, but let's then create a development_Raysect_X.Y branch where the features requiring unreleased Raysect version X.Y can be merged into.

[jacklovell]

I'm not sure I understand correctly what you mean, so I'm sorry if my comment os off topic. For me the system in which the cherab development branch aimed to be working with the raysect development branch was efficient and I thought that anybody who couldn't work with git and python to match working versions was supposed to used pip and master branches. Having to merge several feature brances in order to work on a new one seems quite a pain.

This is fine for those of us working as Cherab developers. But there are plenty of users out there who aren't developing the code, they just want to use the framework in their analysis. It's been 2 years since we last made a Cherab release and so more and more of these users are having to work with the development branch which is trickier to use and more at risk of breaking, just so they can access the features they need. I'd rather the framework were more accessible to non expert users, even if it did come at the cost of more complexity developing on multiple Cherab versions.

Then again, this solution is well solved through the use of separate environments if you want to work with different versions of Cherab and Raysect. Again, as developers we should embrace this without requiring end users to do the same.

This makes sense, but let's then create a development_Raysect_X.Y branch where the features requiring unreleased Raysect version X.Y can be merged into.

I like this idea. Keeps things nicely compartmentalised and so avoids situations where we almost managed to make a Cherab release before a new feature was added which broke compatibility with a released raysect version (we skipped Raysect 0.6.1 and 0.7.0 because of this).

[Mateasek]

I'm happy with what @vsnever suggested.

[jacklovell]

I've just created a new branch, raysect-0.8-compat, which seems to work with Raysect 0.8 (it passes the CI). Any new features you wish to add to Cherab which depend on raysect 0.8 should be submitted as pull requests against this branch, rather than the development branch. Development will retain raysect 0.7.1 compatibility until raysect 0.8 is publicly available.

[vsnever]

Thanks, @jacklovell. I have an idea on how to use this new Intersection feature in ray transfer matrices for surface emitters, which I think might be useful for infrared thermography.

[vsnever]

Closed because it was decided that the Cherab development branch should depend on the Raysect master branch.