RCL a écrit : > Hi, > > On Sun, Mar 2, 2008 at 11:09 AM, Kurosu <[EMAIL PROTECTED]> wrote: > > >> Hi, >> >> RCL a écrit : >> >>> 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 ... >> and >> >>> 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. >> >> The real problem you are alluding is rather the expectation people will >> have about their bug being fixed. But we would certainly not be the >> first project to not fulfill every user's need. And that's not even >> being uncaring for users, just being realistic. >> >> > > 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 releases, it's very practical to know if you are running the latest version or not. As Kurosu said, lot of software use timestamps as version : Ubuntu, Mandriva, MS Office, > 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 ? When I arrive in the project, each release changes the "major" number : 0.3, 0.4, 0.5, 0.6, 0.7 ... > 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. > 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... > 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 agree with "no stress, no (official) plan but let's release!" We have 3 months to discuss about version numbering ;-) Regards, Matt (gentildemon) > > >> Best regards, >> -- >> Kurosu >> >> > > Best regards, > RCL > _______________________________________________ > Wormux-dev mailing list > Wormux-dev@gna.org > https://mail.gna.org/listinfo/wormux-dev > > > _______________________________________________ Wormux-dev mailing list Wormux-dev@gna.org https://mail.gna.org/listinfo/wormux-dev
