Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: General Battuta on November 19, 2015, 07:49:57 pm
-
Hey Chief! Currently dates do not appear in the build's name when you select them in WXLauncher. This makes it hard to work when you're trying to sort out exactly when a bug appeared.
Could we reverse the position of the build key and the date in the build filename? Would that help things? Would it break anything vital?
-
I have a slightly different suggestion. How about replacing the commit hash with a SVN like revision number? It's relatively easy to do with rev-list and wc:
git rev-list <commit>..HEAD | wc -l
The base commit could either be the last release or some arbitrary commit in the past (e.g. 663b3471b9e14c31e7102af8b3f76c1aa465c932 for the source code import), depending on what is easier to implement.
That way we could keep the advantages of SVN revision numbers which are easier to handle than commit hashes that only make sense within the context of the git repository.
-
The goal is to be able to quickly tell which build is newer; the date accomplishes that. The git hash is still useful because there might've been commits later the same day that didn't make it into the Nightly; having the git hash lets someone look that sort of thing up if they need to. Without these "revision number alikes" being in the commit history, they would be useful only for relative ordering, which... again, the date accomplishes.
-
The hash is only useful for developers but not for the end user. The date works for relative ordering, I haven't thought of that.
I'm currently thinking about adding a feature that lets a mod specify which FSO version is needed to play it. There have been a lot of issues with the BP release because people used too old builds. That feature needs some sort of numeric revision in order to determine if a nightly build is supported. I guess the build date is enough for that.
-
The hash is only useful for developers but not for the end user. The date works for relative ordering, I haven't thought of that.
I'm currently thinking about adding a feature that lets a mod specify which FSO version is needed to play it. There have been a lot of issues with the BP release because people used too old builds. That feature needs some sort of numeric revision in order to determine if a nightly build is supported. I guess the build date is enough for that.
Nightly builds already use it as the revision number for basically this exact reason (as in FS_VERSION_REVIS); the November 6th build is therefore 3.7.3.20151106 (and should report as such in the mainhall, debug logs, etc.). The one flaw in the system is basically that wxLauncher is displaying the git hash instead of the date; as Battuta suggested in the original post, this should be fixable by just making the nightly build script swap their order in the filename.
-
Nightly builds already use it as the revision number for basically this exact reason (as in FS_VERSION_REVIS); the November 6th build is therefore 3.7.3.20151106 (and should report as such in the mainhall, debug logs, etc.). The one flaw in the system is basically that wxLauncher is displaying the git hash instead of the date; as Battuta suggested in the original post, this should be fixable by just making the nightly build script swap their order in the filename.
Oh, I wasn't aware of that. Just ignore me then :warp:
-
Well, we still don't have the ability for a mod to specify a specific FSO version it needs (we have version-specific comments, but those aren't quite the same thing... and matches_version_specific_tag() only accepts 3 numbers anyway (the similar scan_fso_version_string() works on anywhere from 1 to 4 values, but doesn't validate the values—just retrieves them—and is only used by FRED for some reason)). So, you know, don't drop the line of thought entirely! ;)
-
I thought the nightly builds didn't contain the revision information which means that it needed to be added. However, that isn't true so the version feature doesn't even need any changes to the nightly system. The version test feature is nearly finished (I just need to do some tests), expect a PR shortly :p
-
Yes, I realized a while back that since I had already written the version injection code for release builds, doing the same thing on nightlies was pretty trivial, so I went and added that in. Now, as for rearranging the date and hash, you would lose the ability for a simple directory sort to display the builds in any meaningful order, alphanumerically speaking. So I'd really rather not adjust the ordering if we can come up with a launcher-side solution for that.