View topic - IMPORTANT: development moves to git


All times are UTC + 1 hour


Post new topic Reply to topic  [ 61 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: 04 Apr 2009, 15:55 
Spring Developer

Joined: 24 Jun 2007, 07:34
Location: 50┬░ 56' N, 11┬░ 35' O
It was not random, it happened when I deleted a fork I accidentally created before.
Top
 Offline Profile  
 
PostPosted: 05 Apr 2009, 10:12 
Spring Developer

Joined: 24 Jun 2007, 07:34
Location: 50┬░ 56' N, 11┬░ 35' O
DOes anyone here uses JGIt / EGit?

Also, it works again.
Top
 Offline Profile  
 
PostPosted: 06 Sep 2009, 15:50 
AI Coder
User avatar

Joined: 17 Oct 2006, 03:14
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
Top
 Offline Profile  
 
PostPosted: 08 Sep 2009, 05:39 
AI Coder
User avatar

Joined: 17 Oct 2006, 03:14
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
Top
 Offline Profile  
 
PostPosted: 10 Sep 2009, 04:17 
AI Coder
User avatar

Joined: 17 Oct 2006, 03:14
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"
Top
 Offline Profile  
 
PostPosted: 10 Sep 2009, 10:35 
Spring Developer

Joined: 24 Jun 2007, 07:34
Location: 50┬░ 56' N, 11┬░ 35' O
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.
Top
 Offline Profile  
 
PostPosted: 20 Nov 2009, 17:55 
AI Coder

Joined: 17 Mar 2008, 19:03
Location: RF
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?
Top
 Offline Profile  
 
PostPosted: 20 Nov 2009, 21:02 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
get a better job.
Top
 Offline Profile  
 
PostPosted: 20 Nov 2009, 21:08 
Lobby Developer
User avatar

Joined: 25 Sep 2006, 12:56
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 )
Top
 Offline Profile  
 
PostPosted: 26 Jun 2011, 17:15 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
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:
File comment: Dia source file (rename to .dia)
engineBranchingModel.txt [4.96 KiB]
Downloaded 32 times
File comment: proposed new branching, tagging and versioning model
engineBranchingModel.png [71.24 KiB]
Downloaded 2 times


Last edited by hoijui on 01 Oct 2011, 10:22, edited 1 time in total.
Top
 Offline Profile  
 
PostPosted: 26 Jun 2011, 17:45 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
... 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>"
Top
 Offline Profile  
 
PostPosted: 27 Jun 2011, 08:57 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
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:
File comment: model RC2 (using ~)
engineBranchingModel_rc2.png [72.4 KiB]
Downloaded 2 times


Last edited by hoijui on 01 Oct 2011, 10:21, edited 1 time in total.
Top
 Offline Profile  
 
PostPosted: 27 Jun 2011, 14:03 
Moderator

Joined: 19 May 2009, 20:10
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.
Top
 Offline Profile  
 
PostPosted: 29 Jun 2011, 09:10 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
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:
File comment: model RC3 (using - and +)
engineBranchingModel_rc3.png [74.18 KiB]
Downloaded 2 times


Last edited by hoijui on 01 Oct 2011, 10:21, edited 1 time in total.
Top
 Offline Profile  
 
PostPosted: 30 Sep 2011, 13:58 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
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, 10:20, edited 1 time in total.
Top
 Offline Profile  
 
PostPosted: 30 Sep 2011, 14:51 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
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
Top
 Offline Profile  
 
PostPosted: 01 Oct 2011, 10:31 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
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
Top
 Offline Profile  
 
PostPosted: 01 Oct 2011, 10:40 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
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.
Top
 Offline Profile  
 
PostPosted: 01 Oct 2011, 19:58 
User avatar

Joined: 30 May 2010, 10:56
Location: France
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: ))
Top
 Offline Profile  
 
PostPosted: 01 Oct 2011, 20:33 
Spring Developer
User avatar

Joined: 22 Sep 2007, 08:51
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
Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 61 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: Google [Bot] and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Site layout created by Roflcopter et al.