advance planning for migration to git

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Message
Author
User avatar
Cjkjvfnby
AI Contributor
Posts: 539
Joined: Tue Jun 24, 2014 9:55 pm

Re: advance planning for migration to git

#16 Post by Cjkjvfnby »

Vezzra wrote:
Cjkjvfnby wrote:1) Git branches are located in single folder. I suggest to include branch name to version.
You mean the name of the currently checked out branch?

Yes. In patch it is omitted if branch is master.

Code: Select all

17 Mar 15 c579cbf
17 Mar 15 inspector e7dfb83
In file name I suggest next schema: FreeOrion-<year>-<month(number)>-<day>-<branch>-<commit>-Test-Win32-Setup.exe
Sort by name will be same as sort by date.
Attachments

[The extension patch has been deactivated and can no longer be displayed.]

If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: advance planning for migration to git

#17 Post by Vezzra »

I have looked at your suggested adjustments to make_versioncpp.py (btw, patch was based on a commit by Geoff to the github mirror repo that he hasn't applied to SVN, so I could not cleanly apply it to my SVN working copy, did that manually), and played around with the possibilities offered by the various git commands a bit. I came up with the following changes:
  • Instead of using "git describe --always" to acquire the commit hash of HEAD, use "git show -s --format=%h HEAD". The output of the former can vary and is therefore more difficult to parse.
  • Take the branch out of the "build number" you compile, and set it between the major version "0.4.4+" and the "build number".
  • To shorten things a bit, compile the "build number" as follows: <2-digit-year-number><2-digit-month-number><2-digit-day-number>.<commit-hash>
  • Most important: Don't get the date from datetime.utcnow(), as that would give you the current date and time of the system. The version string (and therefore any build number constructed using a date/time) must be identical for builds based on the same commit. So fetch the date of the commit instead, and make sure to convert it to UTC.
So the final version string will be something like this: "v0.4.4+ branch [build 150320.831f1b0] Xcode 0511".

Here is what my version of make_versioncpp.py looks like now, with all adjustments:

Code: Select all

#!/usr/bin/python

import sys
import os
from string import Template
from subprocess import check_output
from datetime import datetime

if 3 != len(sys.argv):
    print "ERROR: invalid parameters."
    print "make_versioncpp.py <project rootdir> <build system name>"
    quit()

os.chdir(sys.argv[1])
build_sys = sys.argv[2]
infile = 'util/Version.cpp.in'
outfile = 'util/Version.cpp'

version = "0.4.4+"
build_no = "???"

try:
    branch = check_output(['git', 'rev-parse', '--abbrev-ref', 'HEAD']).strip()
    if branch == "master":
        branch = ""
    commit = check_output(["git", "show", "-s", "--format=%h", "HEAD"]).strip()
    timestamp = float(check_output(["git", "show", "-s", "--format=%ct", "HEAD"]).strip())
    build_no = ".".join([datetime.utcfromtimestamp(timestamp).strftime("%y%m%d"), commit])
except:
    print "WARNING: git not installed"

if build_no == "???" and os.path.exists(outfile):
	print "WARNING: Can't determine git commit, %s not updated!" % outfile
	quit()

try:
    template_file = open(infile)
    template = Template(template_file.read())
    template_file.close()
except:
    print "WARNING: Can't access %s, %s not updated!" % (infile, outfile)
    quit()

print "Writing file: %s" % outfile

version_cpp = open(outfile, "w")
version_cpp.write(template.substitute(
    FreeOrion_VERSION=version,
    FreeOrion_BRANCH=branch,
    FreeOrion_BUILD_NO=build_no,
    FreeOrion_BUILDSYS=build_sys))
version_cpp.close()

print "Building v%s build %s" %(version, build_no)
And here is the accordingly adjusted Version.cpp.in template file:

Code: Select all

#include "util/Version.h"

namespace {
    static const std::string retval = "v${FreeOrion_VERSION} ${FreeOrion_BRANCH} [build ${FreeOrion_BUILD_NO}] ${FreeOrion_BUILDSYS}";
}

const std::string& FreeOrionVersionString()
{
    return retval;
}
Cjkjvfnby wrote:In file name I suggest next schema: FreeOrion-<year>-<month(number)>-<day>-<branch>-<commit>-Test-Win32-Setup.exe
Sort by name will be same as sort by date.
Hm, I'd rather sort by branch first, then by date, and use the build number as constructed above: "FreeOrion-<branch>-<build-number>-Test-Win32-Setup.exe". Using the example above: "FreeOrion-branch-150320.831f1b0-Test-Win32-Setup.exe". When branch is master, omit the branch part.

@Everyone: comments, opinions, other suggestions?

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: advance planning for migration to git

#18 Post by Dilvish »

Vezzra wrote:I came up with the following changes:
To shorten things a bit, compile the "build number" as follows: <2-digit-year-number><2-digit-month-number><2-digit-day-number>.<commit-hash>
Those all looked good to me, but for one comment on the build number-- I personally have a preference for 4 digit years since that reduces uncertainty about how to parse all the date digits, but that's a minor preference here.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: advance planning for migration to git

#19 Post by Geoff the Medio »

The most recent builds / commits as of this writing have version strings of the form ""v0.4.4+ [build 20150406.87ba108] MSVC 2010". Could the date portion of that have some separators inserted to make it more obviously a date number? Perhaps "...2015-04-06..."

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: advance planning for migration to git

#20 Post by Vezzra »

Geoff the Medio wrote:Could the date portion of that have some separators inserted to make it more obviously a date number? Perhaps "...2015-04-06..."
It can certainly be done, however, please consider the following:

* When I came up with this "format" for the new build number, I didn't choose the date-like part for the purpose of having the date of the commit the build is based upon in my build number, but because this was the best/most convenient way I could think of to produce a unique, increasing build number that can be derived from the metadata of a commit (in conjunction with the commit hash of course). Initially I even intended to just use the two-digit year number ("150406"), to make it less obviously a number composed from a date, and also to make it a bit shorter (as it's really long now with the commit hash). I only extended that to use a four-digit year number upon Dilvish' request.

* This build number isn't just used in the version string, it's also used (like the SVN revision number before) in the filenames of the test builds, adding e.g. dashes to the date-like part of the build number would result in those filenames to look like that:

"FreeOrion-2015-04-06.87ba108-Test-Win32-Setup.exe"

...instead of:

"FreeOrion-20150406.87ba108-Test-Win32-Setup.exe"

For all these reasons I'd prefer the build number without any separators in the date-like part, but that's just, well, my personal preference. If you really want me to, I will change it.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: advance planning for migration to git

#21 Post by Dilvish »

Vezzra wrote:I only extended that to use a four-digit year number upon Dilvish' request.
Well, I only made that request because I thought that Vezzra wanted me to know it was a date! :P

OK, I think I kind of do prefer actually seeing it as a date, but I don't currently have a strong opinion about that. If we want to mask the fact that this is derived from a date, and keep it shorter, then using just 2 digits does make plenty of sense.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: advance planning for migration to git

#22 Post by Geoff the Medio »

Vezzra wrote:For all these reasons I'd prefer the build number without any separators in the date-like part...
I see that you didn't intend to make it obviously a date, but not why you don't want it to be obviously a date. What's wrong with a date in the filename?

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: advance planning for migration to git

#23 Post by Vezzra »

Geoff the Medio wrote:I see that you didn't intend to make it obviously a date, but not why you don't want it to be obviously a date. What's wrong with a date in the filename?
Well, nothing is wrong with that, it's just a bit clunky for my taste. "150406.87ba108" is already quite long, especially if you include it into a filename, so "2015-04-06.87ba108" is even worse. But as I said, that's just my personal preference. Dilvish seems to prefer a "date format" too, so we can switch to that, I don't have a very strong opinion on this.

One thing I'd like to avoid is the dashes - maybe "2015.04.06.87ba108" is better? Would that be ok with you, or do you prefer the version with dashes? Dilvish?

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: advance planning for migration to git

#24 Post by Dilvish »

Vezzra wrote:One thing I'd like to avoid is the dashes - maybe "2015.04.06.87ba108" is better? Would that be ok with you, or do you prefer the version with dashes? Dilvish?
The dots look good to me.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Mitten.O
Programmer
Posts: 255
Joined: Sun Apr 06, 2014 4:15 pm

Re: advance planning for migration to git

#25 Post by Mitten.O »

Or you could make the other dashes dots and let the dashes in the date be dashes.

"FreeOrion.2015-04-06.87ba108.Test.Win32.Setup.exe"

YYYY-MM-DD is the standard for dates nowadays. It makes no difference in this case, but so much pain and suffering has been caused and will be caused to programmers all around the world by other date formats, that my instinct is to go for the standard whenever possible. But as I said, it should not matter in this case.

I love how much discussion we are getting out of a simple file name!
Any code by me in this post is released under GPL 2.0 or later.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: advance planning for migration to git

#26 Post by Dilvish »

Mitten.O wrote:YYYY-MM-DD is the standard for dates nowadays.
Uh-oh! Mitten is weakening my support for dots. :lol:
To be more specific about the standard: http://en.wikipedia.org/wiki/ISO_8601
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: advance planning for migration to git

#27 Post by Geoff the Medio »

Mitten.O wrote:"FreeOrion.2015-04-06.87ba108.Test.Win32.Setup.exe"
Seems reasonable to me. I'd probably default to _ instead of . for separators (other than before the final extension), but it's not a strong preference.

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: advance planning for migration to git

#28 Post by Vezzra »

Geoff the Medio wrote:
Mitten.O wrote:"FreeOrion.2015-04-06.87ba108.Test.Win32.Setup.exe"
Seems reasonable to me.
*Sigh* - you guys just love these dashes, don't you? :lol:

Well, ok, but:
I'd probably default to _ instead of . for separators (other than before the final extension), but it's not a strong preference.
Very much agreed. At least lets do that - using the underscore as separator instead of dots: "FreeOrion_2015-04-06.87ba108_Test_Win32_Setup.exe".

Will adjust the respective Python scripts accordingly.
Mitten.O wrote:I love how much discussion we are getting out of a simple file name!
No kidding... :mrgreen:

Post Reply