IMPORTANT: development moves to git - Page 3

IMPORTANT: development moves to git

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Auswaschbar
Spring Developer
Posts: 1254
Joined: 24 Jun 2007, 08:34

Re: IMPORTANT: development moves to git

Post by Auswaschbar »

It was not random, it happened when I deleted a fork I accidentally created before.
Auswaschbar
Spring Developer
Posts: 1254
Joined: 24 Jun 2007, 08:34

Re: IMPORTANT: development moves to git

Post by Auswaschbar »

DOes anyone here uses JGIt / EGit?

Also, it works again.
User avatar
hughperkins
AI Developer
Posts: 836
Joined: 17 Oct 2006, 04:14

Re: IMPORTANT: development moves to git

Post by hughperkins »

Auswaschbar wrote:This also applies to MapConf, MapDesigner and Upspring.
I've added the MapDesigner code to a github repository at:

http://github.com/hughperkins/SpringMap ... ree/master
User avatar
hughperkins
AI Developer
Posts: 836
Joined: 17 Oct 2006, 04:14

Re: IMPORTANT: development moves to git

Post by hughperkins »

Well, I have to say: development on git is absolutely wonderful! It's really a pleasure to work with, to be able to work easily with offline repositories, in McD's or Starbucks or whatever.

Nice work, those responsible for moving to git.

Also, the git submodule functionality is excellent, perfect for AIs.

Hugh
User avatar
hughperkins
AI Developer
Posts: 836
Joined: 17 Oct 2006, 04:14

Re: IMPORTANT: development moves to git

Post by hughperkins »

Hi,

For the AI sub-modules, I assumed they would automatically update from their respective repositories as time goes along, but it seems that in fact they are locked to one specific commit.

For example, E323AI seems to be set to mid-August's version at the moment?

We could submit multiple [patch] requests to run git submodule update occasionally, but that sounds like a lot of work, for Mantis, for the poor developer who runs the update, and for the AI developer, who has to keep making mantis patch requests...

Could we perhaps consider having some kind of batch process, that runs each day, at a certain time, and does:

git submodule update
git commit -m "submodule update"
Auswaschbar
Spring Developer
Posts: 1254
Joined: 24 Jun 2007, 08:34

Re: IMPORTANT: development moves to git

Post by Auswaschbar »

We already discussed that, and it was rejected by most of us. If you want a new version, poke one of us to update it. Its a 20 seconds operation.
slogic
AI Developer
Posts: 626
Joined: 17 Mar 2008, 19:03

Re: IMPORTANT: development moves to git

Post by slogic »

How can i clone repository if git port is blocked by corporate firewall? I was trying to use http port, but git failed to retrieve data. Is it true that the last chance is to download source archive directly?
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: IMPORTANT: development moves to git

Post by hoijui »

get a better job.
User avatar
BrainDamage
Lobby Developer
Posts: 1164
Joined: 25 Sep 2006, 13:56

Re: IMPORTANT: development moves to git

Post by BrainDamage »

slogic wrote:How can i clone repository if git port is blocked by corporate firewall? I was trying to use http port, but git failed to retrieve data. Is it true that the last chance is to download source archive directly?
download trough an http proxy

set $http_proxy env var ( note it's lowercase and afaik it's case sensitive )
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: IMPORTANT: development moves to git

Post by hoijui »

After some discussing with Tobi, i made a diagram to visualize the branching, tagging and versioning model we want to use for the engine.
I hope i got it about as we discussed it. Note that the tagging and versioning are a first draft thing so far.
This whole thing is heavily based on the git branching model shown here:
http://nvie.com/posts/a-successful-git-branching-model/

Once the model is final, i'll but the .dia file into the repo, and the .png somewhere on the wiki.

Questions & Critique please.

RC1
Image
Attachments
engineBranchingModel.txt
Dia source file (rename to .dia)
(4.96 KiB) Downloaded 35 times
engineBranchingModel.png
proposed new branching, tagging and versioning model
(71.24 KiB) Downloaded 2 times
Last edited by hoijui on 01 Oct 2011, 11:22, edited 1 time in total.
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: IMPORTANT: development moves to git

Post by hoijui »

... just figured that the image alone is not enough, doh! :D

When we want to start preparing a release, we branch of a thread from the develop branch, called release. the commit of the branch-off is tagged with <major.minor>.split (the string "split" is subject to change still). The actual spring version (compiled into the engine and unitsync binaries) would be generated from the output of "git describe" (in the case of tarballs, from a file generated like this: git describe > VERSION). This raw output may be any of:
  • 0.83.0.split -> on develop, release or any feature branch
  • 0.83.0.split-12-g48f457e -> on develop, release or any feature branch
  • 0.83.0.0 -> an actual release version (on master)
  • 0.83.0.0-1-g32362fa -> hotfix
As you can see, the 0.83.0.split* versions would be pretty confusing, because one had to check with the hash whether it is a develop, release or feature-branch version of the engine. Thus we would replace "split" with the actual branchs name within CMake, and compile that into the engine, to be used as version. This would lead to versions like this:
  • 0.83.0.develop
  • 0.83.0.release
  • 0.83.0.myCoolNewFeature
  • 0.83.0.develop-1375-g48f457e
  • 0.83.0.release-12-g485f3b0
  • 0.83.0.myCoolNewFeature-33-g32362fa
  • 0.83.0.0
  • 0.83.0.0-1-g42362fa
This makes it much simpler for devs and testers to know what they are testing when looking at the spring version.
Remember that the actual core of the spring version would never contain the 0.83.0.release-12-g485f3b0 part, and that the additional version string could still contain the actual output of git describe, and could look like this:
"0.83.0.develop-1375-g48f457e git:0.83.0.split-1375-g48f457e <other-stuff>"
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: IMPORTANT: development moves to git

Post by hoijui »

One important problem with this idea, which i missed so far:
These versions would all be considered as syncing, which they are not (necessarily):
  • 0.83.0.0
  • 0.83.0.0-1-g48f457e
  • 0.83.0.release-13-g48f457e
  • 0.83.0.develop
  • 0.83.0.develop-9999-g48f457e
  • 0.83.0.myCoolNewFeature-364-g48f457e
-> unacceptable

So i was thinking how we solved this so far, and i had an other DOH moment. So far, we use '+' inside the synced portion of the version, like 0.83.0+.0. With this in mind, i though about replacing the 0.83.0.split tag with 0.83.0+. Instead of replacing "split" with the branch name, we would then simply append ".<branch-name>" as the patch version in CMake.
This way of doing it seems a bit simpler, and prevents some problems even. the only unintuitive thing would be, that the RCs for 0.83.1.0 would look like 0.83.1+.release-1-ga45f29d. We could prevent this by replacing the + with an other char, maybe ~. I think that would make sense, as the + would not be really correct in develop or any other branch it would show up either. 0.83.1+ suggests 0.83.1 plus maybe more (not correct for release nor develop branch), while 0.83.1~ (or 0.83.~1) suggests related to 0.83.1, which makes more sense, i think.

RC2
Image
Attachments
engineBranchingModel_rc2.png
model RC2 (using ~)
(72.4 KiB) Downloaded 2 times
Last edited by hoijui on 01 Oct 2011, 11:21, edited 1 time in total.
SirMaverick
Posts: 834
Joined: 19 May 2009, 21:10

Re: IMPORTANT: development moves to git

Post by SirMaverick »

hoijui wrote:After some discussing with Tobi, i made a diagram to visualize the branching, tagging and versioning model we want to use for the engine.
Looking forward to it. There could be more hot fixes available (e.g. scroll bar in menus) so that you don't have to wait for the next sync release for them.

Do we need different versions that sync each other? Obviously for (minor) releases. But the rest is development versions and you can expect people who use them to get the exact same version.
Any schema for syncing tags should only apply to master, hot fix and release branch.
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: IMPORTANT: development moves to git

Post by hoijui »

SirMaverick wrote:Any schema for syncing tags should only apply to master, hot fix and release branch.
You can even exclude the release branches there. As release branches are allowed to introduce sync breaking stuff.
As a simple rule, you may just look at the minor version (what comes after the second dot). If it matches "^[0-9]$", you can use the "major.minor" version for checking whether it syncs with an other version, otherwise not. only master and hotfix branches may contain such minor versions, and every commit there is versioned this way.

I came up with yet an other idea, which might solve a little issue brought up by jk:
If a game(Lua) or lobby or whatever wants to check if a certain spring version contains at least the commits that eg release 0.83.0 contains, there is no certain way to tell this for any but the master, hotfix and release branches.
So the new model (RC3): When splitting off the release branch, tag the commit as 0.83.0-. When 0.83.0 is released, the release branch is merged into develop, and the release branch gets deleted. we would then tag the merge-back-into-develop commit with 0.83.0+, after which we can be sure that develop (and branching of feature branches) contain everything that is in the release. this was not possible in the previous model until the next release.

RC3
Image
Attachments
engineBranchingModel_rc3.png
model RC3 (using - and +)
(74.18 KiB) Downloaded 2 times
Last edited by hoijui on 01 Oct 2011, 11:21, edited 1 time in total.
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: IMPORTANT: development moves to git

Post by hoijui »

Two new RCs for the branching model.
Problems we try to solve:
* make all versions comparable by standard version comparison algorithms
* hotfixes pollute develop with master/release tags

We try to achieve these by:
* tagging the commit that merges a hotfix into develop
* get rid of the - in version tags

in RC5, we use a "uneven=development, even=release" scheme.

in RC6, all version tags in non-release branches always have a +, either minor+ or patchset+.

RC4
Was a failed attempt, not shown here.

RC5
Image

RC6
Image
Attachments
engineBranchingModel_rc6.png
(67.73 KiB) Downloaded 2 times
engineBranchingModel_rc5.png
(68.42 KiB) Downloaded 3 times
Last edited by hoijui on 01 Oct 2011, 11:20, edited 1 time in total.
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: IMPORTANT: development moves to git

Post by hoijui »

as 5 and 6 fail with common version compare algorithms due to "1+ < 1", now 7.

Basically, after every release, we mark develop as an RC or beta or the like, of the next release.
We always make it a beta of the lowest possible version increase (patchset++), which allows us to make either a patch-set, minor or major release next (for real).

the letter 'd' in the version tags on develop stands for development. maybe dev would fit better. it can technically be any other combination of letters.
edit: Abma and Tobi vote for 'a' (alpha), as it seems to be quite standard.

RC7
Image
Attachments
engineBranchingModel_rc7.png
(68.1 KiB) Downloaded 2 times
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: IMPORTANT: development moves to git

Post by hoijui »

In RC8, we always write the patch-set part of the version string, and add an other number at the end for all development versions (which in practice will always be 1 (and omitted for release versions)).

This kind of combines the pros of RC6 and RC7, with the (in case you see it as such) downside of not omitting the patchset.

RC9 is like RC8, but here we omit the patch-set when it is 0 (as before).
So all dev versions have 4 dots, while release versions may either have 2 or 3.

RC8
Image

RC9
Image
Attachments
engineBranchingModel_rc9.png
(67.56 KiB) Downloaded 2 times
engineBranchingModel_rc8.png
(67.49 KiB) Downloaded 2 times
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: IMPORTANT: development moves to git

Post by hoijui »

Alternatively, to reduce the number of numbers in the version, we could remove the minor version completely, and only have mayor releases from now on. minor ones kind of make no sense with this branching model anyway.
User avatar
daftalx
Posts: 89
Joined: 30 May 2010, 11:56

Re: IMPORTANT: development moves to git

Post by daftalx »

hoijui wrote:Alternatively, to reduce the number of numbers in the version, we could remove the minor version completely, and only have mayor releases from now on. minor ones kind of make no sense with this branching model anyway.
+1. Too many numbers kill numbers (and confuse people using/reading them... "wait, how many zeros am I at already ?" etc.)

!vote RC10 (RC9 minus one digit (which gets weirdly ironic :twisted: ))
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: IMPORTANT: development moves to git

Post by hoijui »

In RC10 we see what was discussed earlier: the minor-version part does not exist anymore. In RC11, i reduced the major version from its current 0.83 form to a single number, starting at 1.

RC10
Image

RC11
Image
Attachments
engineBranchingModel_rc11.png
(63.1 KiB) Downloaded 2 times
engineBranchingModel_rc10.png
(66.49 KiB) Downloaded 2 times
Post Reply

Return to “Engine”