Codenames and version numbers
Moderator: PPS-Leaders
I have to screw things a little bit because I just remembered how you usually handle version bumps:
Consider version 0.5.2. You work on it until you feel that you want to release (or tag) a new version. To do that you bump the version in the source, make a tag/release with version 0.5.3 and continue working.
In our case this doesn't add up except if we were to change the current version to 0.0.1, then bump it to 0.0.2 and make the tag.
What do you think?
Consider version 0.5.2. You work on it until you feel that you want to release (or tag) a new version. To do that you bump the version in the source, make a tag/release with version 0.5.3 and continue working.
In our case this doesn't add up except if we were to change the current version to 0.0.1, then bump it to 0.0.2 and make the tag.
What do you think?
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
Exactly. Unless there are objections of course. But that would have to happen until tomorrow
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
Update:
0.0.2 tag has been stored. You will be working on that version until you think it is time for 0.0.3 or even 0.1.0 (if you have something worthy of such a version number ). The usual procedure would be to increase the version in the second to last commit before making the tag.
The version name is still "Arcturus" though. That will change with 0.1.x. I hope everyone is at least partially happy with this strategy.
0.0.2 tag has been stored. You will be working on that version until you think it is time for 0.0.3 or even 0.1.0 (if you have something worthy of such a version number ). The usual procedure would be to increase the version in the second to last commit before making the tag.
The version name is still "Arcturus" though. That will change with 0.1.x. I hope everyone is at least partially happy with this strategy.
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
The most common versioning scheme is major.minor.patch, so the third number is only for bugfixes (you would have to have a release branch separated from trunk for this task), the middle one for normal changes, and the first one for big changes/rewrites.
Re: Codenames and version numbers
"you would have to have a release branch separated from trunk for this task"
What exactly do you mean? We actually tag every version (including patches) in the "tags" folder. And one day, we might tag 0.1 into the "release" folder.
Anyway, apart from Microsoft's I have hardly ever seen any versioning system than the one you mentioned in your last post. So we should certainly stick to that.
What exactly do you mean? We actually tag every version (including patches) in the "tags" folder. And one day, we might tag 0.1 into the "release" folder.
Anyway, apart from Microsoft's I have hardly ever seen any versioning system than the one you mentioned in your last post. So we should certainly stick to that.
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
You didn't, really? Like every application I know is that way. Just look at cmake for instance: we require v2.6 but we do not care about 2.6.0 or 2.6.1 or 2.6.2, right? Also if I remember correctly this is written in CMakeList.txt in the top Orxonox folder, right?1337 wrote:Anyway, apart from Microsoft's I have hardly ever seen any versioning system than the one you mentioned in your last post. So we should certainly stick to that.
Code: Select all
SET(ORXONOX_VERSION_MAJOR 0)
SET(ORXONOX_VERSION_MINOR 0)
SET(ORXONOX_VERSION_PATCH 2)
SET(ORXONOX_VERSION 0.0.2)
SET(ORXONOX_VERSION_NAME "Arcturus")
Where we cannot see it is in games. You usually buy v1.0.0 and the patches they release can be anything from v1.0.1 to 1.2.x
Or look at Counter-Strike. We never cared about the third version number. Some started with the Beta (0. others started with the full version 1.0 and later upgraded to 1.3 and right now it's 1.6.
Even in old Orxonox we were quicker updating our version numbering. I really wonder when we will reach 1.0 because I really wonder when we even reach v0.1 at this rate ^^. What do we have the major version numbering for if we never use it anyway.
And yes I know I have been overruled by you other guys and I also know that you Reto don't really want to discuss this anymore, but I have to defend my standpoint.
"I'm Commander Shepard and this is my favorite forum on the internet."
Re: Codenames and version numbers
hmm, beni, please read my post again. And pay attention to all the negations and so on...
CMake is btw. a very good example for that versioning system.
And yes, I agree that commercial games might do it differently because they can't really 'release' 0.2 ^^
But who says we shouldn't jump to 1.0 from 0.2 for instance? If we think the orxonox really is a game with more than two levels and some elaborate stuff, why not?
CMake is btw. a very good example for that versioning system.
And yes, I agree that commercial games might do it differently because they can't really 'release' 0.2 ^^
But who says we shouldn't jump to 1.0 from 0.2 for instance? If we think the orxonox really is a game with more than two levels and some elaborate stuff, why not?
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
Oh my, I'm sorry. I guess I'm too tired today.
However the point is the same: We're only working on patches at the moment? And: Every 0.x version must be a full fledged release? You say that we should stick to this version system, but I don't really see that we do.
However the point is the same: We're only working on patches at the moment? And: Every 0.x version must be a full fledged release? You say that we should stick to this version system, but I don't really see that we do.
"I'm Commander Shepard and this is my favorite forum on the internet."
Re: Codenames and version numbers
It is only called "patch"...
Usually you have a minor version branch and work on that. The rule is not to make any interface breaking change, just adding small stuff if required. So for instance OGRE had to add several little functions during the development of 1.4 "Eihort", so you might still require 1.4.5 for instance (the logger has one important function more, I remember).
But yes, they were merely patching up 1.4.0.
My point however is the following: A minor version is something the developers consider "worthy of release". So if Fabian says pong works very well and you can make a death match against 20 space ship flying enemies, I wouldn't disagree to release v0.1.
One major criterion for minor releases is the hacks: How many of the have not been fixed? Some can of course only be fixed with a major new feature, but others are rather small ones. I don't exactly know how many of these we have, but the scoreboard certainly is one.
And I also stick to my argumentation from before: If the game has considerably more to offer than pong and bots (I didn't list the level features like pickup, quest, etc. here), we might jump to 1.0.0.
And as far as I can see there are a few major things to do for that first: Smart pointers incl. level unloading and writing levels plus the new pickup, weapon, etc. stuff. My estimate is that we might be able to release 1.0.0 after HS09, depending on how much has been done of course.
I see the problem with this: 0.0.2 --> 0.1 --> 1.0 or something like that. No versions in between... But nevertheless it serves to have a 1.0 release sooner than later to encourage people to download orxonox.
Usually you have a minor version branch and work on that. The rule is not to make any interface breaking change, just adding small stuff if required. So for instance OGRE had to add several little functions during the development of 1.4 "Eihort", so you might still require 1.4.5 for instance (the logger has one important function more, I remember).
But yes, they were merely patching up 1.4.0.
My point however is the following: A minor version is something the developers consider "worthy of release". So if Fabian says pong works very well and you can make a death match against 20 space ship flying enemies, I wouldn't disagree to release v0.1.
One major criterion for minor releases is the hacks: How many of the have not been fixed? Some can of course only be fixed with a major new feature, but others are rather small ones. I don't exactly know how many of these we have, but the scoreboard certainly is one.
And I also stick to my argumentation from before: If the game has considerably more to offer than pong and bots (I didn't list the level features like pickup, quest, etc. here), we might jump to 1.0.0.
And as far as I can see there are a few major things to do for that first: Smart pointers incl. level unloading and writing levels plus the new pickup, weapon, etc. stuff. My estimate is that we might be able to release 1.0.0 after HS09, depending on how much has been done of course.
I see the problem with this: 0.0.2 --> 0.1 --> 1.0 or something like that. No versions in between... But nevertheless it serves to have a 1.0 release sooner than later to encourage people to download orxonox.
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, now I even less understand your point than before ^^. In my opinion a 1.0 version is far from being achieved as it should also include plenty of story elements so lots and lots of content. Just a few gametypes are not enough for a full fledged 1.0. Your right about the encouragement to download a 1.0 version, but if there is only this little in the 1.0 version, who will care about version 1.1? You kill all anticipation for the next MINOR version if the MAJOR version is shit! In the open-source community you hardly have any 1.0 versions unless it is a really well established application. Most of my apps and libs are below 1.0 and around 0.5 and I have no problem at all with it. I really don't understand your fear of a 0.1 release and the sudden unreasonable willingness to upgrade to 1.0.
I also do not agree that 0.1 has to be something really worthy of releasing. There aren't many applications out there with a usable 0.1 version. Applications are considered a Beta at about 0.6 as far as I experienced, everything before is Alpha and considered highly experimental and now guarantees about compatibility between versions. About hacks and bugs: It really depends more on the development team than the version system. Many 1.0 games are terribly buggy and have hacks all over. Also many commercial software is that way. Open source development teams are more reluctant to call for a 1.0 version, which seems much more sensible and there I agree, but the comparison to other projects is not that easy to apply.
In the end you point out, that we may have something like 0.0.2 --> 0.1 --> 1.0. I agree this is probably what's going to happen at this rate and I think it is highly confusing for most people if there is only one minor version.
I also do not agree that 0.1 has to be something really worthy of releasing. There aren't many applications out there with a usable 0.1 version. Applications are considered a Beta at about 0.6 as far as I experienced, everything before is Alpha and considered highly experimental and now guarantees about compatibility between versions. About hacks and bugs: It really depends more on the development team than the version system. Many 1.0 games are terribly buggy and have hacks all over. Also many commercial software is that way. Open source development teams are more reluctant to call for a 1.0 version, which seems much more sensible and there I agree, but the comparison to other projects is not that easy to apply.
In the end you point out, that we may have something like 0.0.2 --> 0.1 --> 1.0. I agree this is probably what's going to happen at this rate and I think it is highly confusing for most people if there is only one minor version.
"I'm Commander Shepard and this is my favorite forum on the internet."
Re: Codenames and version numbers
wait a moment. We're both missing our points...
If you were doing my bidding, we wouldn't release 1.0 for a very long time. I thought you were eager to do that, so I gave in a little bit. Since that's not the case, we both totally agree on v1.0
About the minor release: I've already said all I think.
To get concrete: What would you have done at the beginning of this semester?
If you were doing my bidding, we wouldn't release 1.0 for a very long time. I thought you were eager to do that, so I gave in a little bit. Since that's not the case, we both totally agree on v1.0
About the minor release: I've already said all I think.
To get concrete: What would you have done at the beginning of this semester?
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 would have defined at least v0.1 and v0.2. Meaning I would have discussed and listed all the features would want to include into those versions. Those lists would have been really realistic and independent from the projects the students would have chosen.
For instance (just from the top of the head without thinking too much about it): I would say v0.1 must include Deathmatch and maybe one more game type. No requirements for the CC as long as the game types can be played. Then I'll list what this includes:
The PPS would be independent of the milestones but not necessarily from the tickets. Instead we would choose tasks (a group of similar tickets) or tickets for the students to do. There we would of course consider difficulty and time consumption as well as balance between coding and CC and not milestone affiliation.
In the end, this means we would work on the milestones in parallel which means that v0.1 may include features which were only a requirement for v0.2 and not for v0.1. Of course this could also mean that v0.2 could be finished before v0.1. This of course would only happen if the initial definition of v0.1 and v0.2 were stupid ^^. Also patch version number would become close to irrelevant as we would rarely create versions in between milestones. But we could use those later for important features for minor versions and bug fixes. The patch version would of course only increment if we'd do a release.
I know it's maybe not the best way to go and I'm sure that while thinking about it a bit more we could identify some no goes in this approach and avoid those.
In the end I project a much more sensible version numbering and more goal oriented work. Of course it would mean that 0.1 is maybe not great, but would hold a few minutes of fun. Also a readme file would provide the user with the necessary knowledge to use the console to create bots or load a different level using the command line. Such a readme file would be written in a few hours and greatly increase user friendliness.
For instance (just from the top of the head without thinking too much about it): I would say v0.1 must include Deathmatch and maybe one more game type. No requirements for the CC as long as the game types can be played. Then I'll list what this includes:
- Fix the AI
- Create Pong
- Give the player a nicer GUI where he can choose the game type.
- ...
The PPS would be independent of the milestones but not necessarily from the tickets. Instead we would choose tasks (a group of similar tickets) or tickets for the students to do. There we would of course consider difficulty and time consumption as well as balance between coding and CC and not milestone affiliation.
In the end, this means we would work on the milestones in parallel which means that v0.1 may include features which were only a requirement for v0.2 and not for v0.1. Of course this could also mean that v0.2 could be finished before v0.1. This of course would only happen if the initial definition of v0.1 and v0.2 were stupid ^^. Also patch version number would become close to irrelevant as we would rarely create versions in between milestones. But we could use those later for important features for minor versions and bug fixes. The patch version would of course only increment if we'd do a release.
I know it's maybe not the best way to go and I'm sure that while thinking about it a bit more we could identify some no goes in this approach and avoid those.
In the end I project a much more sensible version numbering and more goal oriented work. Of course it would mean that 0.1 is maybe not great, but would hold a few minutes of fun. Also a readme file would provide the user with the necessary knowledge to use the console to create bots or load a different level using the command line. Such a readme file would be written in a few hours and greatly increase user friendliness.
"I'm Commander Shepard and this is my favorite forum on the internet."
Re: Codenames and version numbers
Thank you very much for these extensively described thoughts.
It does sound very good, I must say! (Also because I like the OGRE project and they follow this concept ).
It has however a major catch, which I personally would not lay upon our project: multiple 'trunks'.
What I really mean is that there would still be the trunk with most recent features and bug fixes. At the same time there would be a 0.1 and a 0.2 branch. And most importantly one person (like sinbad for OGRE) would be responsible to merge all the bugfixes and features around. I once subscribed to the OGRE commit mailing list and you could see those merges (always in chunks) happen quite often.
Or do you see another possibility?
It does sound very good, I must say! (Also because I like the OGRE project and they follow this concept ).
It has however a major catch, which I personally would not lay upon our project: multiple 'trunks'.
What I really mean is that there would still be the trunk with most recent features and bug fixes. At the same time there would be a 0.1 and a 0.2 branch. And most importantly one person (like sinbad for OGRE) would be responsible to merge all the bugfixes and features around. I once subscribed to the OGRE commit mailing list and you could see those merges (always in chunks) happen quite often.
Or do you see another possibility?
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 see what you mean and I imagine that this is maybe inevitable.
However, the problem you describe is that Ogre needs to maintain more than one version and provide bug fixes for both or just one version and that's what will result in those merges, as far as I understand this.
Ogre needs to do that because they don't provide a final product and others depend on the maintainability.
Since Orxonox is a final product we can just dismiss old versions. What we will need is maybe a patch for several releases, but I don't think we have to maintain several trunks. We just have one trunk and only make a release when we reached a milestone. When there are features for future version in that release that shouldn't be a problem. Or do I miss something?
However, the problem you describe is that Ogre needs to maintain more than one version and provide bug fixes for both or just one version and that's what will result in those merges, as far as I understand this.
Ogre needs to do that because they don't provide a final product and others depend on the maintainability.
Since Orxonox is a final product we can just dismiss old versions. What we will need is maybe a patch for several releases, but I don't think we have to maintain several trunks. We just have one trunk and only make a release when we reached a milestone. When there are features for future version in that release that shouldn't be a problem. Or do I miss something?
"I'm Commander Shepard and this is my favorite forum on the internet."
Who is online
Users browsing this forum: No registered users and 2 guests