IMPORTANT: development moves to git
Moderator: Moderators
-
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
Re: IMPORTANT: development moves to git
It was not random, it happened when I deleted a fork I accidentally created before.
-
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
Re: IMPORTANT: development moves to git
DOes anyone here uses JGIt / EGit?
Also, it works again.
Also, it works again.
- hughperkins
- AI Developer
- Posts: 836
- Joined: 17 Oct 2006, 04:14
Re: IMPORTANT: development moves to git
I've added the MapDesigner code to a github repository at:Auswaschbar wrote:This also applies to MapConf, MapDesigner and Upspring.
http://github.com/hughperkins/SpringMap ... ree/master
- hughperkins
- AI Developer
- Posts: 836
- Joined: 17 Oct 2006, 04:14
Re: IMPORTANT: development moves to git
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
Nice work, those responsible for moving to git.
Also, the git submodule functionality is excellent, perfect for AIs.
Hugh
- hughperkins
- AI Developer
- Posts: 836
- Joined: 17 Oct 2006, 04:14
Re: IMPORTANT: development moves to git
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"
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"
-
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
Re: IMPORTANT: development moves to git
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.
Re: IMPORTANT: development moves to git
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?
Re: IMPORTANT: development moves to git
get a better job.
- BrainDamage
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
Re: IMPORTANT: development moves to git
download trough an http proxyslogic 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?
set $http_proxy env var ( note it's lowercase and afaik it's case sensitive )
Re: IMPORTANT: development moves to git
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
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
- 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.
Re: IMPORTANT: development moves to git
... 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:
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>"
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
- 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
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>"
Re: IMPORTANT: development moves to git
One important problem with this idea, which i missed so far:
These versions would all be considered as syncing, which they are not (necessarily):
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
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
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
- 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.
-
- Posts: 834
- Joined: 19 May 2009, 21:10
Re: IMPORTANT: development moves to git
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.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.
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.
Re: IMPORTANT: development moves to git
You can even exclude the release branches there. As release branches are allowed to introduce sync breaking stuff.SirMaverick wrote:Any schema for syncing tags should only apply to master, hot fix and release branch.
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
- 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.
Re: IMPORTANT: development moves to git
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
RC6
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
RC6
- 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.
Re: IMPORTANT: development moves to git
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
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
- Attachments
-
- engineBranchingModel_rc7.png
- (68.1 KiB) Downloaded 2 times
Re: IMPORTANT: development moves to git
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
RC9
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
RC9
- Attachments
-
- engineBranchingModel_rc9.png
- (67.56 KiB) Downloaded 2 times
-
- engineBranchingModel_rc8.png
- (67.49 KiB) Downloaded 2 times
Re: IMPORTANT: development moves to git
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.
Re: IMPORTANT: development moves to git
+1. Too many numbers kill numbers (and confuse people using/reading them... "wait, how many zeros am I at already ?" etc.)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.
!vote RC10 (RC9 minus one digit (which gets weirdly ironic ))
Re: IMPORTANT: development moves to git
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
RC11
RC10
RC11
- Attachments
-
- engineBranchingModel_rc11.png
- (63.1 KiB) Downloaded 2 times
-
- engineBranchingModel_rc10.png
- (66.49 KiB) Downloaded 2 times