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.
Codenames and version numbers
Moderator: PPS-Leaders
Re: Codenames and version numbers
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
Re: Codenames and version numbers
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.
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."
Re: Codenames and version numbers
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.
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.
A webcomic of romance, sarcasm, math, and language.
Re: Codenames and version numbers
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.
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."
Re: Codenames and version numbers
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
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.
A webcomic of romance, sarcasm, math, and language.
Re: Codenames and version numbers
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."
Who is online
Users browsing this forum: No registered users and 1 guest