Codenames and version numbers

Topics about the general development of Orxonox.

Moderator: PPS-Leaders

How should we call our releases?

Names of heroes from games
0
No votes
Names of villians from games
3
21%
Names of stars, planets
10
71%
Names of alcoholic beverages brands
0
No votes
Names of races from <insert scfi universe of your choice>
0
No votes
Names of catastrophes
1
7%
 
Total votes: 14

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Re: Codenames and version numbers

Post by 1337 » Fri Apr 03, 2009 8:35 pm

Hmm, how do you want to separate features then? While some features could be excluded by a preprocessor directive or simply by not compiling some files, other features like the game state rewrite would have to be separated via different SVN folders.

Let me make an example: 5 out of 7 people are working on version 0.1 (bugfixes, improvement, features, etc.) and 2 are working on brand new features that will be incorporated in v0.2.
You then create a branch called v0.2 at some time for these two and maybe two more branches fore them individually. So they work on that 0.2 branch all the time.
And now consider the moment where we abandon 0.1: All the revisions from the v0.2 branch are being merged into the trunk (which was v0.1) and live goes on.
Sounds pretty doable, but there are two catches: Maybe too many conflicts resulting in a lot of merge work. And the v0.2 guys might be very interested in getting new features from 0.1 or even more the recent bugfixes.
You end up merging everything from the trunk (0.1) to the v0.2 as you code. And then at a certain point you replace the trunk with the v0.2 branch.
Or like OGRE: The trunk contains all features and bugfixes from all version branches at all the times. But that's not necessary for us.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Re: Codenames and version numbers

Post by beni » Fri Apr 03, 2009 11:00 pm

I don't want to separate features. That's exactly my point. Who cares if there is stuff from milestone v0.2 in v0.1? It's just for us to be able to define what really works.
Like this we won't have to change anything. We would still have just one trunk and everybody has his branch doing his feature (v0.1 or v0.2, I don't care) and merges it when it is finished. When all features for v0.1 are merged we release it as v0.1.0 and just keep coding on v0.2 stuff.
If 0.2 people want something from the 0.1 people we just create a new branch, like we do now. I think everything else over complicates the problem.
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Re: Codenames and version numbers

Post by 1337 » Sat Apr 04, 2009 11:17 am

I see.. We simply keep the branches related to not 'excludable' (like rewriting of existing stuff) v0.2 material out there and merge them as soon as we start working on v0.2 (when the last v0.1 patch has been released).
Everything else (most of it) that can easily be excluded (or things that could even reside in the repository without anyone using it yet) would be merged into the trunk anyway. For instance the quest system might go into v0.2, but we already merge it and keep in mind that it belongs to the v0.2 milestone. (And we simply don't use it yet because it is v0.2 or else it would have to be v0.1).
I hope I didn't explain my thoughts too complicatedly.

Sounds pretty reasonable tough.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Re: Codenames and version numbers

Post by beni » Sat Apr 04, 2009 11:51 am

Pretty complicated ^^, but I think that's the picture I have in mind. I think we can create a v0.1 with v0.2 stuff in it and still have a complete and working v0.1. Of course it needs some thinking and reasonable organization or we end up merging or being unable to merge important things, because we have stupid definitions of those milestones.
In the end, I think having a plan in the first place is better than executing it thoroughly and standing in our own way if it happens to be not as well thought out as expected.
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Re: Codenames and version numbers

Post by 1337 » Sat Apr 04, 2009 3:30 pm

yeah, it might be complicated. As I said, there is only one problem I see: Larger rewriting projects like the objecthierarchy branch in the past. If one of these is scheduled for a next milestone, we might want to wait with merging.

So, I think that we've settled most of the points, very well ;)
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Re: Codenames and version numbers

Post by beni » Sun Apr 05, 2009 11:35 am

Okay, I agree. There may be branches and major changes (mostly in the core I guess) which would render this way of working on the project a bit complicated, but I think we'll manage.
"I'm Commander Shepard and this is my favorite forum on the internet."

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests