Update version number for the coming release

[timmiesmith]

The PR updates the oneDPL version macro and test verifying it. This PR should not be merged until code freeze for the coming release.

[dmitriy-sobolev]

Let's also update this place:

oneDPL/documentation/library_guide/conf.py

Line 40 in 9a1dada

release = '2022.7.0'

[timmiesmith]

Let's also update this place:

oneDPL/documentation/library_guide/conf.py

Line 40 in 9a1dada

release = '2022.7.0'

Done. Thanks for the pointer.

[danhoeflinger]

Looks good to me. It may be a good idea to separate addition ONEDPL_SPEC_VERSION and the version update to different commits if it is not too much trouble.
I can see us wanting to be able to find both of these in the git log history in the future.

[timmiesmith]

Looks good to me. It may be a good idea to separate addition ONEDPL_SPEC_VERSION and the version update to different commits if it is not too much trouble. I can see us wanting to be able to find both of these in the git log history in the future.

Would mention of both in the commit line be sufficient? I'm not sure how to split a PR into two separate commits when we merge.

[danhoeflinger]

Would mention of both in the commit line be sufficient? I'm not sure how to split a PR into two separate commits when we merge.

Yeah that's probably fine as long as they are both in the top line.

If you want to split to 2 commits it would probably involve manually rebasing it locally to the commit separation you want and then force pushing (reapproving), then using "rebase and merge" from github rather than "squash and merge".

As I write this I actually see that we have lost the ability to "rebase and merge" in the change to UXL. I've used it in the past to do similar things. Its rare but useful. We may want to look into reenabling that feature.