Add developer docs section on: Releases and maintenance & simplify propagating version number throughout codebase

[edwardchalstrey1]

Closes #560

@tturocy @rahulsavani I believe this captures the current processes as they stand, let me know if not

Page: https://gambitproject--628.org.readthedocs.build/en/628/developer.contributing.html#releases-maintenance-branches

See also the comment below on the addition of the GAMBIT_VERSION file

[edwardchalstrey1]

This is a non-exhaustive list, @tturocy do you tend to update the version number in all these places and elsewhere when releasing, or is there one place where the version number gets propagated throughout the codebase?

[tturocy]

It's done manually. It could be useful to use one of the various version-bumping tools that's out there to help automate this.

[tturocy]

At the risk of some scope creep, would it be a good idea whilst we are in the neighbourhood to rationalise the locations of the various build-support files?

At the moment we have:

• contrib/mac for OSX build (contrib/ definitely not the right place for that!)
• GAMBIT_VERSION is in .
• gambit.wxs.in in .

(Separately note I've removed the very old gambit.spec and gambit.desktop which are long obsolete.)

It would seem a good idea to to have a directory for these - what would be a good name (build of course doesn't work that's already in use!). And then presumably the generated versions of these files should go under build/ somewhere appropriate.

[tturocy]

See note in conversation about thinking about directory structure for input files, and putting generated files in build/ somewhere.

[edwardchalstrey1]

At the risk of some scope creep, would it be a good idea whilst we are in the neighbourhood to rationalise the locations of the various build-support files?

At the moment we have:

• contrib/mac for OSX build (contrib/ definitely not the right place for that!)
• GAMBIT_VERSION is in .
• gambit.wxs.in in .

(Separately note I've removed the very old gambit.spec and gambit.desktop which are long obsolete.)

It would seem a good idea to to have a directory for these - what would be a good name (build of course doesn't work that's already in use!). And then presumably the generated versions of these files should go under build/ somewhere appropriate.

@tturocy I have moved these into build_support

[tturocy]

I've pushed a few further amendments:

• The old, non-.in versions of the files were still under version control - and further actually some of the build scripts were referring to those and not to the generated ones.
• Moved everything in build support into OS-specific directories for symmetry.

Waiting to see whether the actions run into any problems, but it would also be good to check my work!

[tturocy]

@edwardchalstrey1 @rahulsavani Looks like the GitHub actions ran successfully, so no obvious internal problems. Can you both please have a look to see whether we have done everything here that it makes sense to do as far as rationalising the organisation of the build config and SPOTing the version number? Once we've done that we'll get this merged (it's going to make releasing so much easier...)

[edwardchalstrey1]

@edwardchalstrey1 @rahulsavani Looks like the GitHub actions ran successfully, so no obvious internal problems. Can you both please have a look to see whether we have done everything here that it makes sense to do as far as rationalising the organisation of the build config and SPOTing the version number? Once we've done that we'll get this merged (it's going to make releasing so much easier...)

Looks good to me