Date: Fri, 21 Apr 95 21:39 CDT From: uhclem%nemesis@fw.ast.com (Frank Durda IV) To: hackers@FreeBSD.org Subject: Release stability and timing Message-ID: <m0s2V65-0004vtC@nemesis.lonestar.org>
next in thread | raw e-mail | index | archive | help
[0]I don't know who said this but it doesn't matter: (just a lead-in) [0] [0]In the old DEC world there was a three piece cycle that was followed [0]many times. A feature release followed by a robustness release. There [0]was also a performance release that followed the robustness release. They also used Major number, Minor Letter, and Edit numbers for everything, including major release titles. So you had stuff like Release 3(1234) (nearest translation 03.00.1234) which was the major release 3. Then shortly would come Release 3A(1345) (nearest translation 03.01.1345), which was supposed to be a collection of minor fixes but no major structural changes. I have always felt that Major release numbers for an operating system should be incremented if: 1. Sysadmins have to reformat or build new filesystems to use it. This should be because of a significant improvement in architecture, not because someone didn't want to keep existing formats in place or some other unnecessary enhancement, such as longer volume ID strings. If you changed the format of tar, cpio or other backup media, that would get you a Major release rating. OR 2. Sysadmins have to recompile or relink existing software to get it to work with major system functions (such as password database, libc, time management, etc). Having to recompile the fortune or hunt program doesn't count as a critical function. OR 3. Some vast collection of new hardware is supported. Supporting last years tape drive in a brighter orange cabinet doesn't count. Adding support for Firewire peripherals or nine varieties of ISDN and DSU interfaces from six vendors might be good enough for a major release if there were a lot of people who had them or would instantly buy them. Common sense check: how many benefit vs the pain and expense of the upgrade? OR 4. Some major processing facility or facilities is added to the system (in the operating system or provided applications/utilities) that someone would be willing to upgrade for. (Stability is assumed and should not be listed as an significant excuse for any major release.) In our case, say the ability to execute SCO binaries, Windows binaries or Linux binaries would certainly qualify. Rewriting CRON to have a graphical interface (as an example) would not count as a reason for a major release. OR 5. You have several minor releases out since the last major release and it is becoming a hassle for everyone to manage layering stuff. This rule actually ensures that if the product is alive and evolving, you will get major releases from time to time even as the system matures and major changes hopefully decline. Of these five items, the #3 and #4 are weaker and by themselves really shouldn't qualify a major revision number. #3 and #4 together or either #3 or #4 with one of the other conditions is good enough for a major release. Minor revision numbers are used to distribute collections of fixes, small enhancements, forgotten man pages and utilities, performance improvements, added support for the one or two peripherals (not a full subsystem like SCSI), etc. These are turned out at either regular intervals, or in response to some threshold. This threshold can be: the customer support pain threshold (such as the the "we can get all these people off our backs with this" release), or the visibility/competitive threshold (the "why are we letting this neat stuff just sit when people could be using it and annoying the competition" reason). The second threshold is constantly encouraged by the marketing side of things so always set that threshold higher than the prior to avoid feeble releases that make it look like interest in your product is declining. By using letters for the minor field, they purposely limited themselves on how far they could go without a major relase, but I only know of one major product (from DEC) that went to "E" before they did a major release. Effectively that would be six minor releases between major releases, which in the DEC install scheme they provided fifteen years ago was a pretty big pain. (Using letters also helped cut down on confusion caused by version ID dyslexia.) Finally, Edit increments (in DEC/ANSIese the number in the parens, in the Microsoft/Letni world the nn.nn.XX part of the version number), is used to indicate this is newer than the last version and something is different. That's all. Our nearest equivalent would be somewhere between -current and SNAPs, probably closer to SNAPs in structuring. Released as regularly as practical, and usually only of interest to those people with a specific issue. The vendor may not even offer the complete OS at a given edit level, just certain chunks of the system. So in our scheme, maybe the ports tree would have more edits than the sys tree, etc. These things probably would be available only via online rather than on stamped media. Also, the edit numbers never went back to zero; they just keep climbing, making some types of source control easier. DEC used Octal for edit numbers, but ANSI doesn't require that. I'd like to see FreeBSD try to move in the direction of setting better goals for the next major (and less major) releases, regardless of whether we use Microsoft or ANSI version stamps. (I think Microsoft has won the version stamp format war.) I think this type of release goal outline would take some of the pressure off and eliminate throwing every inanimate object in sight into the major releases at the last minute. By agreeing early (like shortly after the last major release) as to what the major components of a major release are going to be and holding the line to that set of major changes, it really helps hold the line on delivery scheduled. It may even allow key people to double-up on certain large projects, rather than each try to push his pet project thru in parallel. To a lessor extent you do the same thing with smaller pieces of the system (auxillary apps, new drivers, improvements, major corrections, etc), possibly having three or four milestones between releases for submission of those items. If something misses two milestones between major releases, you relax and say that item isn't going to be part of the next major release unless there is tons of agreement to do otherwise. On the other hand, something major that didn't make the goal list for the next major release but gets finished early and proves itself in minor releases may gain a seat in the next release if there is agreement. There is no need to treat this as a Yes-No situation. Now if you had asked me two weeks ago (early to mid April), I would say that anything that wasn't in the SNAPs on that day that is going to require the user to make new filesystems, cause any existing compiled binaries to not work, or require lots of modules to be reworked (even slightly) should be held off for the next major or minor relase, say 2.1.>0 or even 2.2.0. But since then it was decided to cut a minor release first so that we could continue to stuff big items into 2.1, and delay 2.1 until late summer. I dunno, I think bugs aside the SNAPs have enough big features to be popular as they stand now. It would be better to put any other big stuff on hold and focus on bug fixes. Some serious consideration should really be placed on whether to put 2.1 off so long for the sake of a few big and possibly risky items. Geez, the Linux camp will release two discs in that amount of time, not including the variants: Linux-on-a-stick, Linux-in-a-bag, etc. It seems that we may be beyond Creeping Elegance and be up near Lunging Elegance. Hey, I love having tons of features and a feature bullet list that wraps all the way around the box, but if all the features have got bugs and the delivery schedule starts looking like one from Microsoft, was the time spent well and will they wait? On another subject, and not being in California may have something to do with this, I always felt blind regarding the SNAP schedules. Unlike every other software project I was ever involved with, I have never known when the door is going to close on submissions so that a SNAP can emerge later. If even a tentative date for the next snap was announced several days in advance and roughly when the snap AFTER the next one might occur, it would help avoid the rush we see now. You could even close the door at the announced time for small and minor submissions and hold off building the SNAP if some major fix or other important piece was to arrive shortly. For example, I happened to see a reply to someone else that SNAP-0412 was appearing at any minute. It was posted on 0413. Despite this, I rushed to try to get some stuff in for that SNAP, not knowing if it was the one that would become 2.1. Turns out it didn't, but that information just isn't making it out and it really should. Since then I have discovered I can tell when a SNAP is in the making by just looking the volume of the cvs mail for a given day. Its sorta like the Washington press watching the pizza places around the White House to discover when something is going on. :-) I would also suggest that SNAPs never be closer together than ten to 14 days. It's all just a thought from someone who has managed a few UNIX releases. (No, don't ask.) :-( Frank Durda IV <uhclem@nemesis.lonestar.org>|"The Knights who say "LETNi" or uhclem%nemesis@fw.ast.com (Fastest Route)| demand... A SEGMENT REGISTER!!!" ...letni!rwsys!nemesis!uhclem |"A what?" ...decvax!fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0s2V65-0004vtC>