REL: backport #960 to v2.5.2

[mj-will]

Back port #960 to v2.5.x to make v2.5.2.

[mj-will]

I've checked and I think this would produce the correct version:

$ git log -5 --oneline
66b74c5f (HEAD -> backport-#960-to-v2.5.2, origin/backport-#960-to-v2.5.2) CHANGELOG: prepare v2.5.2
d02b08f7 BUG: fix the filename extension precedence for result files (#960)
83245aee (tag: v2.5.1, upstream/backport/v2.5.2, backport/v2.5.2) CHANGELOG: update for v2.5.1 (#951)
fab9326d BUG: Use "geocent" not "geocenter" where appropriate (#930)
bbf5ac46 BUG: fix injection parameters being fixed during recovery (#931)
$ git tag v2.5.2
$ pip install -e . --dry-run --no-deps
Obtaining file:///home/michael/git_repos/bilby
  Installing build dependencies ... done
  Checking if build backend supports build_editable ... done
  Getting requirements to build editable ... done
  Preparing editable metadata (pyproject.toml) ... done
Would install bilby-2.5.2

[ColmTalbot]

I'm happy to merge this, can you do a test run of what version we get on main after this tag is made?

[mj-will]

I'm happy to merge this, can you do a test run of what version we get on main after this tag is made?

Good point, I checked and it does get a bit messy:

$ git log --oneline -n 5
f6b6258d (HEAD -> main, upstream/main, upstream/HEAD) BUG: fix the filename extension precedence for result files (#960)
94e66a21 Merge pull request #958 from mattpitkin/doc_fix
6258f9d9 run_sampler: correct use_ratio docs
22cc23a1 BUG: Fix sampling efficiency warning (#953)
6b3fb3af ENH: plot_multiple: Allow plotting onto user-defined figure (#946)
(nessai) [michael@r9l-icgphd7 bilby]$ python -m setuptools_scm
2.5.2.dev6+gf6b6258d

If the tag were in main, I think it should be 2.5.3.dev#

This won't happen once #954 is merged but in the meantime we'll have to decide how to handle this. I think we have two options:

• Accept the version will be wrong until we make the next tag
• Merge the release/v2.5.2 branch back in to main after the release has been made

What do you think?

[ColmTalbot]

This won't happen once #954 is merged but in the meantime we'll have to decide how to handle this. I think we have two options:

• Accept the version will be wrong until we make the next tag
• Merge the release/v2.5.2 branch back in to main after the release has been made
  What do you think?

I think the latter here is better, I don't think we should delay the release too much trying to figure out the best way to do this.

[mj-will]

This won't happen once #954 is merged but in the meantime we'll have to decide how to handle this. I think we have two options:

• Accept the version will be wrong until we make the next tag
• Merge the release/v2.5.2 branch back in to main after the release has been made
  What do you think?

I think the latter here is better, I don't think we should delay the release too much trying to figure out the best way to do this.

Okay, sounds good to me.