Matthieu Fertré wrote: >>>> Please, leave major.minor.patch numbering. Ubuntu's way is confusing, >>>> > > Hum, currently we do not use major.minor.patch numbering. We use > 0.major.minor ...
I'd say, no, we do have something like: major.middle.minor The middle number makes sense (in the 0.x.y timelife): 8 is networking 9 is AI And we never bumped the major version to 1.x.y because we know the game is incomplete, since we are still working on networking and the AI is, well, AI-stupid! Also, we never did any major code overhauls, like change the physics engine to use ODE, or made a rewrite of some big parts of the code, or reworked the graphics in such a way that the game feels *totally* different or new/distinct. >>>> you get version numbers misleadingly bumped up, even if no major changes >>>> happened (e.g. people could think that 9.01 is significantly better than >>>> 8.12, though they may only differ by minor patches). >>>> >>> Well, isn't the later what we'd like? We are not interested that much in >>> bug reports about old versions, so any incentive to update frequently >>> and test the latest is good IMO. That also drives your users away. We *have* a lot of bugs and that is the feeling many users get, and those bugs are reported and open in the tracker (I know I haven't done much to fix that), but we have enough work now to keep us busy for an year, at least. BTW, gentildemon is doing a GREAT job! Thanks! >> Using Ubuntu's numbering, version numbers are actually just timestamps - the >> same way we could package snapshots from svn and name them wormux-080302 etc >> :) And given that the development effort is not going at the same pace as >> time does, this can render version numbers meaningless. >> > > And what is the problem with timestamp ? When you know the frequency of It brings little, if any, valuable information. (See motivation below for this statement.) > releases, it's very practical to know if you are running the latest > version or not. And with that you summed up *ALL* the benefits, moreover, that information might not be of any use at all (for instance, a really stale /slow development cycle during for that release). Also, that sole "benefit" doesn't counter the fact that you might not have *any* interest to run the latest stuff (say, you play just via network and don't care about AI). How will you easily see that, as a user? You can't just by looking at the number, because is meaningless. > As Kurosu said, lot of software use timestamps as version : Ubuntu, > Mandriva, MS Office, And they suck, really! Because you have no way of knowing at a glance, if they fixed that darned problem that I wanted them to fix, or if I must upgrade because this release fixes important security issues, or I should because that nice Avahi integration finally happened, or if they made a major change in the code I should wait until .1 arrives because is a known fact that X.0.0 releases sux0r big time, because they usually imply major code overhauls. >> We would also have no way of letting the users know that major changes >> happened in the code as we couldn't just bump up version number for a >> particular release. >> > > And what is a major change that justify or not a change of major version ? See above. > When I arrive in the project, each release changes the "major" number : > 0.3, 0.4, 0.5, 0.6, 0.7 ... Probably because either: A. the project managed to do major/medium changes (redone graphics, new sets of weapons, reworked physics, rework menus) B. the project wasn't mature enough to consider patch releases as important as getting the "ball rolling", sort of speak C. the project wasn't mature Also, do you expect the project to be in a continuous strive to develop/stabilize that it doesn't warrant to think we'll never be able to get that AI code out the door, or the physics engine changed? That really saddens me, since I feel a note of abandonment in this "release numbers are time stamps". MANY other projects go the other way around, use time stamps at first, then switch to real major.minor.patch numbers like wine. And they switch when they "start to see the light", when they feel confident enough that they will get soon some clear goals for the release, or they already did. They didn't knew when that would happen when they were using time stamps. So my question is? Is it not clear that 0.8.x should be about networking, while 0.9.x should be about AI? How about 1.0.0? Can't we all see is about delivering the first version that we can be proud of, because it has a decent AI, and the networking works between any two, three or whatever number of players and that, independent of the arch they are playing on? COME ON PEOPLE! DON'T GIVE UP! >> And about not fullfilling expectations - I think that situation when the >> users download 9.01 and find out that is not really different from >> 8.12kills the "incentive to update" (for those unaware of versioning >> scheme) at >> least until 10.1 is out. I wholeheartly agree! It would actually kill the users that we already have. Really, this would be a step back. (And is not a "step back" as in "let's step back a little to see the big picture".) > Sometimes major changes are difficult to see by users. Imagine for > instance a user which never plays in network game, network game is not a > major change for him. It's exactly the same for lot of features... Yes, but he will expect to see something different if the minor number changes, it is expected, after all, it is how many users' minds are trained. And actually, he will see something. Remember, such a bump would have to have a visible reflection in the game, even if that means there's a new menu entry, I guarantee, he *will* see it. >> I'd propose fixed release cycle with version number based _solely_ on number >> of changes (and their significance) from the previous version. That way, no >> goals are defined for a particular version and there's no stress about >> missing the deadline - if we're not ready with some feature we (unoficially) >> planned for this cycle, the game still gets released, but only minor version >> number gets incremented. I find this idea a really good compromise and it would probably provide us with the version scheme we want. As I understand, it would mean that we could have this valid sequence of releases: 0.8.1, 0.8.20, 0.8.21, 0.8.78, 0.9.0, 0.9.1, 0.9.45.... Which would roughly translate to something like: - 0.8.21 was a bugfix release (we screwed up 0.8.20, which was more featureful than 0.8.1), - oh, boy, you should *really* try 0.9.1 (not 0.9.0, which we screwed up a little), it has that AI stuff you've been waiting for so long - better get a look at 0.9.45, that AI stuff got some really cool fixes and that AI will beat your ass goodbye now, it has some really cool brainwaves and some bugfixes, too, definetly, you should try it! > I agree with "no stress, no (official) plan but let's release!" I agree. -- Regards, EddyP ============================================= "Imagination is more important than knowledge" A.Einstein _______________________________________________ Wormux-dev mailing list Wormux-dev@gna.org https://mail.gna.org/listinfo/wormux-dev
