From: Torrey M. <Torrey.McMahon@Sun.COM> - 2004-08-28 19:16:11
|
Sean Egan wrote: >Or, we can take the opportunity to create an entirely new versioning >scheme. This would help the people who are constantly confused that >0.x means "doesn't work well" and stay away from Gaim because of it. >I would personally consider "Gaim v84", i.e. dropping the 0. >altogether. That fits more with the whole "this is the 84th version >of Gaim ever," thing, anyway. > It's not really that big of a deal but ... 1) Certain packaging systems, like blastwave, key off the version number. I don't think jumping from "0.82.1" to "84" would be a problem but it would be be if it ever changed again. ("Let's go back to X.YY.ZZ.") 2) To some people the "0.X" versioning implies something about the stability of the codebase. Usually, that it's alpha/beta level all sorts of things can change without notice. (Like the plugin API.) Moving to the "vXX" scheme makes it harder to distinguish. Just my $.02. |
From: Torrey M. <Torrey.McMahon@Sun.COM> - 2004-08-30 17:14:15
|
Ethan Blanton wrote: >Another important fact to consider is that "no-breakage-no-matter-what" >is completely unreasonable to expect from Gaim; protocol changes, for >one, make this impossible. With the pace of Gaim development, backport- >ing such critical fixes to a version even a few months old can rapidly >become a time-consuming task. > >Obviously maintaining a stable and an unstable branch _can_ be done, as >many projects do so. However, it requires developer time and effort, of >which we do not seem to have a surplus. > The hard part seems to be delineating between the core code and quick protocol changes. Perhaps it's time to start looking into separating the gaim code, that could easily used with a major.minor.micro naming scheme, and the protocol code, which looks like it changes much more, into separate distros? I know it lives in different parts of the tree now but making them independent could help with the versioning issues. P.S. -1 to the vXX naming if I get a vote. :) -- Torrey McMahon Sun Microsystems Inc. |
From: Luke S. <lsc...@us...> - 2004-08-30 17:47:08
|
On Mon, Aug 30, 2004 at 01:14:12PM -0400, Torrey McMahon wrote: > The hard part seems to be delineating between the core code and quick > protocol changes. Perhaps it's time to start looking into separating the > gaim code, that could easily used with a major.minor.micro naming > scheme, and the protocol code, which looks like it changes much more, > into separate distros? I know it lives in different parts of the tree > now but making them independent could help with the versioning issues. this is an interesting idea, we currently have sametime implemented as a separate install from the meanwhile project, we probly could make separate packages for each protocol each depending on the base gaim install. static protocol builds already have trouble (just try getting msn to work with the ssl stuff still as a plugin), this would tend towards (but not require) breaking that further, but that's something that seems to be happening anyway. it would also make things like silc easier. the big down sides as i see it are two-fold. 1)the thousands of people upgrading via rpm and deb that would suddenly be protocol-less. 2)users are guaranteed to get confused when they have to install 2 or more rpms just to use gaim. i'm frankly not sure that this can be overcome given our user base. luke |
From: Ethan B. <ebl...@cs...> - 2004-08-30 17:46:52
|
Torrey McMahon spake unto us the following wisdom: > Ethan Blanton wrote: > >Obviously maintaining a stable and an unstable branch _can_ be done, as > >many projects do so. However, it requires developer time and effort, of > >which we do not seem to have a surplus. >=20 > The hard part seems to be delineating between the core code and quick=20 > protocol changes. Perhaps it's time to start looking into separating the= =20 > gaim code, that could easily used with a major.minor.micro naming=20 > scheme, and the protocol code, which looks like it changes much more,=20 > into separate distros? I know it lives in different parts of the tree=20 > now but making them independent could help with the versioning issues. No way ... now, not only are we talking about maintaining separate branches of the Gaim code, but maintaing separate _packages_. This isn't dividing work, it's multiplying it. :-) > P.S. -1 to the vXX naming if I get a vote. :) So, for the record ... why do people find 0.X less offensive than simply X? (This is rhetorical ... don't everyone reply to the list.) I agree that prepending a 'v' is a bad idea, simply because it would confuse many package managers -- but the concept is fine. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Luke S. <lsc...@us...> - 2004-08-30 17:59:16
|
On Mon, Aug 30, 2004 at 12:46:49PM -0500, Ethan Blanton wrote: > > So, for the record ... why do people find 0.X less offensive than simply > X? (This is rhetorical ... don't everyone reply to the list.) I agree > that prepending a 'v' is a bad idea, simply because it would confuse > many package managers -- but the concept is fine. the consensus seems to be that if we stay with 0.x the version numbering might magically become more informative ;-) luke > > Ethan |
From: Andrew S. <gt...@ma...> - 2004-08-30 19:26:34
|
On Mon, 2004-08-30 at 13:58, Luke Schierer wrote: > On Mon, Aug 30, 2004 at 12:46:49PM -0500, Ethan Blanton wrote: > > > > So, for the record ... why do people find 0.X less offensive than simply > > X? (This is rhetorical ... don't everyone reply to the list.) I agree > > that prepending a 'v' is a bad idea, simply because it would confuse > > many package managers -- but the concept is fine. > > the consensus seems to be that if we stay with 0.x the version numbering > might magically become more informative ;-) Sean opened this discussion up with saying: Or, we can take the opportunity to create an entirely new versioning scheme. and suggestion the Gaim v?? scheme. We're not trying to say the numbers will "magically" become more informative. It seems more like a call to make try to make them more informative, or, like myself and at least Christian Hammond said, a plea not to remove the ability to make them more informative one day. Who knows? Maybe one of these major things will become stable enough that somebody really thinks it's time to take that plunge and call something 1.00. The status and libgaim thing are massively future goals with no real roadmap to define when they will happen. That doesn't mean that whenever they're finished it will be any less significant. -- Andrew Sayman <gt...@ma...> |
From: Luke S. <lsc...@us...> - 2004-08-30 19:45:28
|
On Mon, Aug 30, 2004 at 03:26:57PM -0400, Andrew Sayman wrote: > On Mon, 2004-08-30 at 13:58, Luke Schierer wrote: > Sean opened this discussion up with saying: > Or, we can take the opportunity to create an entirely new versioning > scheme. > > and suggestion the Gaim v?? scheme. > > We're not trying to say the numbers will "magically" become more > informative. It seems more like a call to make try to make them more > informative, or, like myself and at least Christian Hammond said, a plea > not to remove the ability to make them more informative one day. i don't see how switching from 0.84 to 84 (note the no v) would preclude someday doing a 99.1 or making 98 "stable" and 99 "unstable" with 98.x and 99.x releases. basically i'm just saying in a world where you can have multiple decimal places and where 2.4.27 is newwer than 2.4.3 (kernel versions) we _have_ to use call our current releases all minor releases to be able to create minor releases at some later point. > > Who knows? Maybe one of these major things will become stable enough > that somebody really thinks it's time to take that plunge and call > something 1.00. The status and libgaim thing are massively future goals i would say that 1.0's create far too much hype to ever be worth releasing one. i'd rather see a 90.x and 91.x release series in parallel than a 1.0 release ever. > with no real roadmap to define when they will happen. That doesn't mean > that whenever they're finished it will be any less significant. the thing is i don't see these as :massively future goals". i see them as very obtainable goals that just requre a month were 2 or 3 of us have free time at once. that hasn't happened yet, but these things are sooo close to being possible its not funny. luke > -- > Andrew Sayman <gt...@ma...> |
From: Ryan B. <gai...@ry...> - 2004-08-30 19:32:20
|
On Mon, 30 Aug 2004, Ethan Blanton wrote: > So, for the record ... why do people find 0.X less offensive than simply > X? (This is rhetorical ... don't everyone reply to the list.) replying to the list...so shoot me. :P imho, two reasons. first, consistency with an established standard. granted, this only carries weight in some cases, but i think this is one of those cases. second, > many people and programs expect to get meaningful information from a version > number....and many programs will just fail. that seems like a Bad Thing. for example, some package managers might choke. (sure, maybe they *shouldn't*, but that's a different debate.) -Ryan -- "I do not like all these things that I used to..." -Brad Wolfe |
From: Luke S. <lsc...@us...> - 2004-08-30 19:47:10
|
On Mon, Aug 30, 2004 at 12:32:05PM -0700, Ryan Barrett wrote: > On Mon, 30 Aug 2004, Ethan Blanton wrote: > > >many people and programs expect to get meaningful information from a > >version > >number....and many programs will just fail. that seems like a Bad Thing. > > for example, some package managers might choke. (sure, maybe they > *shouldn't*, > but that's a different debate.) if we litterally have a v there yes, probly. if we don't then no, they already handle using digits of pi as a version number (5 digits of pi is newwer than 4 digits of pi), they can handle 82, 83, 84, 85... luke > > -Ryan > |
From: Sean E. <sea...@gm...> - 2004-08-30 20:19:40
|
I'll weigh in again with some conclusions I've reached from this thread. It seems most people acknowledge that there is no real difference between 0.84 and 84, and most people agree that given our current style of development, 84 seems more appropriate. Everyone acknowledges that our current version numbers are meaningless, and dropping the oh-dot would make that more obvious to the user. Most people agree that Gaim probably could benefit from more complicated release engineering, and that changing the versioning system should reflect that, even if we're mostly too busy to actually change our release methodologies in the near future. People would like to know which releases are more stable than others; although this depends on a change in our release habits (mainly having a stable tree versus a development tree), a new versioning scheme should have a way to represent that. Once status and privacy is reimplemented, and "libgaim" is complete, it will be crucial to maintain API and ABI compatibility for plugins and other UIs. The version number should definitely represent this. 1.0 is a hyped up deal for marketing types. People go crazy and drool over them because they think everything's changed and perfect and they think we should have parties and everything. People treat it like a huge milestone. I don't ever see a release of Gaim that would live up to that expectation as we release so frequently (something most people appreciate). Similarly, x.0 is seen as significant change over (x-1).0, which it most likely never will be. So, seeing as there are no immediate plans to change our development substantially, it seems for now we should drop the 0. and worry about everything else when we get there, even if it means changing the versioning system again. If anyone can give some concrete examples as to how making Gaim v83 the next version might make any of the above impossible, please reply. -s. |
From: Luke S. <lsc...@us...> - 2004-08-30 20:45:03
|
On Mon, Aug 30, 2004 at 04:19:31PM -0400, Sean Egan wrote: > I'll weigh in again with some conclusions I've reached from this thread. <snip> > versioning system again. If anyone can give some concrete examples as > to how making Gaim v83 the next version might make any of the above > impossible, please reply. just a reminder that we are currently on v0.82, the 'v' is already there, just look at help->about. > > -s. |
From: Kevin M S. <ks...@us...> - 2004-08-30 21:01:40
|
Sean Egan wrote: > So, seeing as there are no immediate plans to change our development > substantially, it seems for now we should drop the 0. and worry about > everything else when we get there, even if it means changing the > versioning system again. If anyone can give some concrete examples as > to how making Gaim v83 the next version might make any of the above > impossible, please reply. The only potential problem (that has already been brought up) is that if we decide later we want to version such that we have x.0 or x.y.z release versions, we will have to do something like 94.0 or 94.1.7, because we can't ever go to 1.0, or package managers will be greatly confused. As long as 94.1.4.5.3 is okay, and we never want to reduce that first number below whatever the last release number is before our change, we should be eternally fine. Kevin |
From: <to...@wc...> - 2004-08-30 23:31:58
|
> 1.0 is a hyped up deal for marketing types. People go crazy and drool > over them because they think everything's changed and perfect and they > think we should have parties and everything. Ok, so what reason do you propose for a party then? What kind of leader tells his developers "no party"?. ;) Topher Manager of Internet Services Cornerstone Broadcasting Cornerstone University ------ "To scoff is...easy, but to go on in the way of scoffing and do what is right is the way of a man." -- Louis L'Amour, The Lonesome Gods |
From: Tim R. <om...@ho...> - 2004-08-31 05:49:12
|
> > >So, seeing as there are no immediate plans to change our development >substantially, it seems for now we should drop the 0. and worry about >everything else when we get there, even if it means changing the >versioning system again. If anyone can give some concrete examples as >to how making Gaim v83 the next version might make any of the above >impossible, please reply. > >-s. > The only thing I saw against v83 was it's a big number, and we can never change our mind and decide we want to use a little major number again, without breaking package managers and the like. Here's some random thoughts of my own, not arguing any side, more thinking outloud. Most people seem to expect a major.minor.micro versioning scheme. Gaim only gives the appearence of using that now (well actually major.minor). No longer giving that appearence might be a good thing, since it's a false impression. Still, everyone has already learned about the major.minor.micro scheme. Certain things are expected when each of these numbers increases. It's hard to unlearn the signifigence, even if you know we're not using that scheme. Going from Gaim v83 to Gaim v84 mentally feels like a major change, even though I know better. As another example, we released a 0.82.1, even though our versioning scheme doesn't include a micro number. I'm guessing due to the external influence of micro numbers all around us, we slipted and used one. Not doing what the user expects is considered bad UI. Yahoo! Messenger uses a scheme of major.minor.micro build #. I recently accepted a patch to make us send "6,0,0,1710" because some guy needed it for his firewall to like Gaim or something, and it didn't hurt anything. Anyway that means yahoo 6 (6.0.0) build #1710. I'm going to suggest a scheme of x.y.z build #83, where x y and z are numbers pulled out of the collective asses of the soon to the formed Gaim Marketing Department. I'm not saying I like this idea, just that I noticed Yahoo! using it, and I didn't see it mentioned yet in this thread. But then I haven't seen the Roman numerals mentioned yet either. --Tim |
From: Ethan B. <ebl...@cs...> - 2004-08-31 13:23:35
|
Tim Ringenbach spake unto us the following wisdom: > The only thing I saw against v83 was it's a big number, and we can never= =20 > change our mind and decide we want to use a little major number again,=20 > without breaking package managers and the like. So ... while I would be opposed to a versioning scheme which required manual intervention at all times, this particular problem is solvable. For RPM, for example, we would simply change the epoch in the specfile from 1 to 2, and this problem would magically go away. That's not to say that shrinking version numbers don't have other eccentricities, but this particular problem shouldn't be a showstopper. :-) Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Christian H. <ch...@gn...> - 2004-08-31 16:02:44
|
On Tue, Aug 31, 2004 at 08:23:31AM -0500, Ethan Blanton wrote: > Tim Ringenbach spake unto us the following wisdom: > > The only thing I saw against v83 was it's a big number, and we can neve= r=20 > > change our mind and decide we want to use a little major number again,= =20 > > without breaking package managers and the like. >=20 > So ... while I would be opposed to a versioning scheme which required > manual intervention at all times, this particular problem is solvable. > For RPM, for example, we would simply change the epoch in the specfile > from 1 to 2, and this problem would magically go away. That's not to > say that shrinking version numbers don't have other eccentricities, but > this particular problem shouldn't be a showstopper. :-) That's RPM. RPM isn't the only packaging system out there, as you know. It will break stuff, and it will confuse people if we ever decide to switch back. Forcing us to use just major numbers from now on prevents us from ever deciding to change things in a clean way in gaim again. None of us may even be on the project a few years from now. We just don't know yet. I wouldn't want to make this decision for our future selves or anybody else who is in charge at some point in the future. Now, why is it that we haven't adopted a major.minor.micro scheme? I know there's the whole argument that people then expect major numbers to equal how good the release is, and all that. Yeah, it's stupid, but this vXX thing may cause even more confusion, and likely we'll get comments about how we're doing it so we seem newer than other clients. Which is stupid, but I guarantee it. (Man, this is a flashback to another project. History repeats itself.) When we have libgaim, we may very well want major.minor.micro. Sure, the gaim binary can be vXX, or v0.XX, or v12.34.67.XX, or whatever, but libgaim should probably fall back on a major.minor.micro, and we should be more careful about what we do with it. Fortunately, whatever change we make for gaim doesn't really have to affect libgaim, but I'm just throwing that out there. Anyhow, I'm still pretty strongly against it, and before just going and making some decision, we really should reach a consensus, as best as we can. Sean states in his e-mail that "most people acknowledge that there is no real difference between 0.84 and 84, and most people agree that given our current style of development, 84 seems more appropriate." I've been seeing more people disagree with the vXX scheme than agree with it, so I'm not sure where that comes from, but let's not make a decision right away. Nobody says we have to make this change now. Oh, and as I said before, v0.83 wasn't the 83rd release. Remember the entire 0.59.x series. We blew this a long time ago, guys. People don't care what release number we are. If we want that information, let's store it in some other string in the about dialog. Users just want to know it's a release that's going to work for them, as do I. Christian --=20 Christian Hammond <> The Galago Project ch...@gn... <> http://galago.sourceforge.net/ BUFFERS=3D20 FILES=3D15 2nd down, 4th quarter, 5 yards to go! |
From: Sean E. <sea...@gm...> - 2004-08-31 16:37:04
|
On Tue, 31 Aug 2004 09:02:30 -0700, Christian Hammond <ch...@gn...> wrote: >Sean states in his e-mail that "most people acknowledge > that there is no real difference between 0.84 and 84, and most people > agree that given our current style of development, 84 seems more > appropriate." I've been seeing more people disagree with the vXX > scheme than agree with it, so I'm not sure where that comes from, but > let's not make a decision right away. Nobody says we have to make this > change now. I haven't seen a single person say "let's keep our current versioning scheme, and have every release forever be zero dot whatever. Everyone agrees that doing that would be effectively the same, but better than dropping the zero dot. Plenty of people have expressed interest in switching to a more meaningful scheme than either of those, but even those seem to admit that 84 is the same, but better, than 0.84. I guess I probably just misunderstood everyone. -s. |
From: Luke S. <lsc...@us...> - 2004-08-31 16:49:39
|
On Tue, Aug 31, 2004 at 12:36:15PM -0400, Sean Egan wrote: > > I haven't seen a single person say "let's keep our current versioning > scheme, and have every release forever be zero dot whatever. Everyone > agrees that doing that would be effectively the same, but better than > dropping the zero dot. Plenty of people have expressed interest in > switching to a more meaningful scheme than either of those, but even > those seem to admit that 84 is the same, but better, than 0.84. I > guess I probably just misunderstood everyone. something is inconsistent here, either the 2nd and 3rd lines are wrong or the 5th and 6th lines are ;-) luke > > -s. |
From: Ka-Hing C. <ja...@ja...> - 2004-08-31 06:56:45
|
On Mon, 2004-08-30 at 22:48, Tim Ringenbach wrote: > and I didn't see it mentioned yet in this thread. But then I haven't > seen the Roman numerals mentioned yet either. Let it be vLXXXIV. Notice how the lower case v stands for version, not 5. -khc |
From: Peter L. <spa...@si...> - 2004-08-31 07:06:11
|
Ka-Hing Cheung wrote: >On Mon, 2004-08-30 at 22:48, Tim Ringenbach wrote: > > >>and I didn't see it mentioned yet in this thread. But then I haven't >>seen the Roman numerals mentioned yet either. >> >> > >Let it be vLXXXIV. Notice how the lower case v stands for version, not >5. > >-khc > > > personally, after further thought and being told off for my Solaris comment, I think we should revert back to original arabic numbering system (not the bastardised numbers we use now, the originals). I'll let you know what 8 4 is once I work out the damned charmap :/ P. |
From: Luke S. <lsc...@us...> - 2004-08-31 11:31:30
|
On Mon, Aug 30, 2004 at 11:56:46PM -0700, Ka-Hing Cheung wrote: > On Mon, 2004-08-30 at 22:48, Tim Ringenbach wrote: > > and I didn't see it mentioned yet in this thread. But then I haven't > > seen the Roman numerals mentioned yet either. > > Let it be vLXXXIV. Notice how the lower case v stands for version, not > 5. that was suggested in #gaim yesterday, and i must say the part of me amused by all the todo over version numbering likes it ;-) on a side note, i'm sure that package managers would hate it. luke > > -khc > |
From: Sean E. <sea...@gm...> - 2004-08-31 12:02:50
|
On Mon, 30 Aug 2004 23:56:46 -0700, Ka-Hing Cheung <ja...@ja...> wrote: > Let it be vLXXXIV. Notice how the lower case v stands for version, not > 5. I suggested making the next version version 5, so that Tim could release gaim-vv vV. -s. |
From: Luke S. <lsc...@us...> - 2004-08-31 16:31:04
|
On Tue, Aug 31, 2004 at 09:02:30AM -0700, Christian Hammond wrote: > That's RPM. RPM isn't the only packaging system out there, as you > know. It will break stuff, and it will confuse people if we ever > decide to switch back. true, if we need to switch back. > > Forcing us to use just major numbers from now on prevents us from ever > deciding to change things in a clean way in gaim again. None of us may i STILL fail to see how 90.x.x or what-have-you isn't clean. <snip> > Now, why is it that we haven't adopted a major.minor.micro scheme? I > know there's the whole argument that people then expect major numbers > to equal how good the release is, and all that. Yeah, it's stupid, but > this vXX thing may cause even more confusion, and likely we'll get > comments about how we're doing it so we seem newer than other clients. > Which is stupid, but I guarantee it. > possibly, just like now i frequently see people saying they are going to wait for gaim to be "stable" since its an "alpha" rlease (0 major version number). > When we have libgaim, we may very well want major.minor.micro. Sure, the > gaim binary can be vXX, or v0.XX, or v12.34.67.XX, or whatever, but > libgaim should probably fall back on a major.minor.micro, and we agreed. > should be more careful about what we do with it. Fortunately, whatever > change we make for gaim doesn't really have to affect libgaim, but I'm > just throwing that out there. exactly, that's irrelevent. <snip> > as we can. Sean states in his e-mail that "most people acknowledge > that there is no real difference between 0.84 and 84, and most people > agree that given our current style of development, 84 seems more > appropriate." I've been seeing more people disagree with the vXX i've been seeing people disagreeing with BOTH 0.84 and 84, but not with one or the other. > scheme than agree with it, so I'm not sure where that comes from, but > let's not make a decision right away. Nobody says we have to make this > change now. that still leaves the question of what to call the next one unresolved. is it 0.83 or 0.84? or something else? > Oh, and as I said before, v0.83 wasn't the 83rd release. Remember the > entire 0.59.x series. We blew this a long time ago, guys. People don't that was off of the gtk1-stable tree, i see that as different, just as i see 0.82.1 as not really being a release, and thus the next one would be 0.83 if we don't change format. > care what release number we are. If we want that information, let's > store it in some other string in the about dialog. Users just want to > know it's a release that's going to work for them, as do I. the thing i see is that we are currently using that information, accurate or inaccurate, in the version number, with a 0. pre-pended to it. this IS misleading. as Tim noted, misleading isn't good. i see going to 83 from 0.83 as acknoledging that we aren't doing major.minor.micro, but are simply itterating. i do think, however, your reply is a perfect example though of the point that someone (Tim?) made, that major.minor.micro may be so imbeded in our collective conciousness that we cannot at this point escape from it in gaim, and that anything we use as a version number will be evaluated in terms of it. of course that coudl be seen as an arguement for LXXXVIII as a version number, no way to fit roman numerals into major.minor.micro ;-) basically though, sitting still has no default value. that means no waiting indefinitally, we have to decide how to sit still (at 0.83. 0.84, or 0.82.2?). i do not see us as we exist now as being able to maintain major.minor.micro development between now and the release of a libgaim. after that we will be able to evaluate "does this still work with the stuff linking against the last version of libgaim or not" but now we can't do that, so its hard to evaluate what qualifies as a major and a minor version from what is a micro version. luke > > Christian > |
From: Andrew S. <gt...@ma...> - 2004-08-31 16:58:26
|
On Tue, 2004-08-31 at 12:30, Luke Schierer wrote: > i do not see us as we exist now as being able to maintain > major.minor.micro development between now and the release of a > libgaim. > after that we will be able to evaluate "does this still work with the > stuff linking against the last version of libgaim or not" but now we > can't do that, so its hard to evaluate what qualifies as a major and a > minor version from what is a micro version. > > luke > A name change that might make sense right now would be a toolkit.release.plugin_api. 2.0.8 or 2.83.8. There will be a new gtk+ one day, and, just like before, it will probably result in another tree for a while. This numbering scheme also has the immediate benefit of skipping a 1.0 ever. You'll never even have something that looks like 1.0 (which would happen under the v?? system at v100). It also doesn't say anything about stability, just what other people need to have around for this release. It bypassess the question of what is and isn't stable in a world where companies claim it's too hard to interroperate and then change their algorithms to kick you ever other day. -- Andrew Sayman <gt...@ma...> |
From: Torrey M. <Torrey.McMahon@Sun.COM> - 2004-08-31 16:53:42
|
Bleeter Yaluser wrote: >Personally, I didn't see it hurting Solaris when they moved from 2.6 to >Solaris 7. A little bit of marketplace confusion initially, leading to a >position where 2.7 or 2.8 were not considered 'minor' releases. So >maybe, for no apparent reason, I'd vote for 8.3, 8.4, 8.4.1, etc. > >P. > ...but uname doesn't. That's the important thing. page% uname -a SunOS page 5.10 s10_66 sun4u sparc SUNW,Sun-Blade-1000 Solaris 10 is still a "minor" release according to our internal rules about such things. -- Torrey McMahon Sun Microsystems Inc. |