Interviewed by CNN on 09/07/2011 19:59, Rostyslaw Lewyckyj told the world: > Let's call a spade a spade! > > The most appropriate label for the "rapid-release train versioning > system" is > "The CONSTANT BETA system". > Especially with your suggestion of never fixing bugs on an existing > version, "It'll (maybe) be fixed in the next (or some future) release" > there is no hope of ever achieving any bugwise stable plateaus.
"Beta" is just a label. It means different things in different contexts. For a Google website, for instance, it can mean "opened for business years ago and is used by millions of people worldwide." The rapid-release model does have a beta stage, but you are artificially applying the definitions of a different development model to it. And it does bother to fix bugs. The main difference is that in the rapid-release train, you don't hold any new features which are ready for users for some future "feature" release -- you include them in the first release out the door. So it's not so much "don't do bugfix releases," it's "include the new features in the bugfix release." > Of course SM is constrained in this, by it's need to follow along > the lead of FF and TB in its internal structure, and thus most > external features and development path and type of label progression. > (i.e. if FF/TB introduces a new feature or reorganizes the code base > and ups its version number, then SM dare not keep its current version > number and only change the modification level number) > Actually, the SM Council has the freedom of using any numbering scheme they want for their product -- Gecko numbering is out of their hands, however. For the moment, they chose incrementing the minor version number as the most appropriate (differently from Firefox, I might add). They *could* in theory have released 2.2 as "2.1.1", but that wouldn't reflect the fact that there were changes to the Gecko engine adding features. 2.2 is more than a bugfix release, despite the fact that the parts the Seamonkey Dev group was directly involved with were mostly bugfixes. However, I don't think minor-version increments is the best long-term numbering strategy any more than Chrome or Firefox's serial major-version increment is: at some point, the "minor" version number will become ridiculously high, and the program will have evolved so much that you could no longer argue that it's "essentially the same as 2.0, with some improvements". So it will be time to go from, say, 2.17 to 3.0. Only the change will seem very arbitrary, because 2.17 will be far more similar to 3.0 than to 2.0. In the rapid-release system, version numbers don't tell us anything useful beyond which release is newer. Since the changes are spread out over a number of releases instead of collected and launched all at once, you cannot guess offhand how different are two consecutive releases from the numbers alone. Moving to a date-based numbering would at least tell us how old is a given release. -- MCBastos This message has been protected with the 2ROT13 algorithm. Unauthorized use will be prosecuted under the DMCA. -=-=- ... Sent from my owl mail. *Added by TagZilla 0.066.2 running on Seamonkey 2.1 * Get it at http://xsidebar.mozdev.org/modifiedmailnews.html#tagzilla _______________________________________________ support-seamonkey mailing list [email protected] https://lists.mozilla.org/listinfo/support-seamonkey
