I've been watching this thread, perhaps my comments are worth something, or are amusing. Executive summary: track -current. Make releases in step with OpenBSD.
On Tue, 28 Aug 2007, Kevin Cheng wrote: > Artur, > > Thanks, > > Upgrade code based on release of obsd is easy, but it would a big job to > maintain early released of products based on previous version of obsd. For That sentence contains its own solution: do not maintain old versions. How would one maintain old versions if the underlying OS is frozen? Attempt to back-port fixes. You know this is hard. > example, we would maintain 8 version of products from 3.3 to 4.0 if codes > are upgraded every half years. How do you answer customers who ask why they can't run the up-to-date version of OpenBSD? If your salesman contacted me, saying I had to *downgrade* my OS to Open 3.3 to run your product, I would advise him to call me again when you can support the current OS. Perhaps you should evaluate your development and support cycle. If you support other host OS's besides OpenBSD, then perhaps it would be worth it to put your applications under control of CVS and your releases in some kind of nice package (like an OpenBSD port) and invest in the effort to get autoconf and related tools working with it. A nightmare for you: suppose you are several versions behind the OpenBSD release and a "Category 5" bug afflicts all OS's derived from Tahoe TCP/IP code... Naturally, OpenBSD has the first patches out, but not for the antique versions you support. Now suppose OpenBSD has done something "significant" (like a.out->ELF, a new file system, big rewrite of code so that patches don't apply smoothly, removed support for something evil, whatever) since you last upgraded your apps, so that you can't just recompile and go. Your phones are ringing...your lead developer is on vacation...few of your clients have Old Version source code...A significant package (gnome or java, say ;-) ) is no longer available... Your software uses a bug-feature of gcc withdrawn after a class-action lawsuit... Suppose instead you had been tracking OpenBSD-current and keeping your apps compliant...[*] the patches for the Bug-of-the-Decade appear in -current in about three hours, another three hours and a snapshot is built, you get the snapshot, your apps compile and regress correctly. You then apply the patches for the other supported versions of Open (3 max), and notify your clients/users. You and Open are back in business first, before M$ can even issue a series of denials that Bug-of-the-Decade exists, or certain pseudo-free OS's can grovel and obtain NDAs from SCO. Instead of getting phone calls, you make them: "Mr Valued Client, emergency update to counter Bug-of-the-Decade is available". Client: "What bug is that?" You: "The one you no longer have to worry about." This makes for much goodwill with the client. [*] tracking -current and keeping your apps "married" to -current is how to make a smooth release of your stuff almost immediately after the OpenBSD release is made (or in the best case, simultaneously). An added benefit: as a commercial or other professional developer, you may well discover serious objections to or bugs with a newish feature of OpenBSD while it is in the embryonic phase -- these objections/bugs are easily fixed at this point, either by your end or OpenBSD's, depending. This benefits everyone. Dave
