So, just edited and updated the OP once more to reflect the latest progress. As the migration of the repo is now complete, it's now time to take care of the cleanup steps.
Marcel already mentioned a few things:
adrian_broher wrote:* Delete all merged branches to remove clutter. So every branch except: master, release-v0.4.4 and logging-migration.
Just to be sure before I proceed with that step: Anyone any objections? If yes, let him now speak or forever hold his peace.
* Delete the release-v0.4.4 branch. The release has already a tag, which keeps the history alive and we don't work on a bugfix release for v0.4.4 so no branch is required here IMO.
I suggest to wait a bit, in case we change our mind and decide we want to merge the branch into master after all.
* Delete the v0.4.4-rc* tags. Tags do mainly map to releases on github. I don't think that end users are really interested into our internal testing release candidates.
Long overdue, done.
If or how we migrate the open tickets and feature requests from sourceforge to github.
Dilvish and I already expressed a preference for closing down the trackers on SF and use the github issues tracker in future. Still waiting for Geoff to make the final call. Then we need to figure out how
to do that: I know how to remove these trackers from the freeorion project on SF (which will delete their entire contents), but it might be more sensible to keep them and just make them read-only. Not sure if that's possible, and if it is, how to do that.
As for porting open tickets to github, if we really want to do that, I don't think there's any other way than manually recreating them... ugh. Which raises the question: Do
we want to do that?
Now to the things still left from the list in the OP of this thread:
* Adjusting build number composition (that includes file name scheme of binary releases, both test and stable) and the Python script that produces version.cpp and the version string. I've already posted a proposal
, I'll probably make that into a pull request (have to learn how to do that anyway).
* Update the SDKs. I'll do the OSX SDK of course, Geoff, if you want me to, I can also take a look at the Windows SDK.
* Decide on what needs to be changed/updated about the FreeOrion project on SF:
** What to do with the repo? Should it stay as a read-only backup, should we remove it entirely? I definitely prefer keeping it as a read-only backup (meaning, leaving it as it is now - commit access has already been revoked from everyone except project admins).
** What should be changed on the front page to indicate the official repo is now on github? What are our options anyway? At least the text needs to change to state that the SF repo is now only a legacy repo kept for backup purposes, and provide a link to the official repo on github.
* Continue publishing binary releases on SF, or is there a similar feature on github, and if, shall we use that instead?
Pls add you 2 cents