Aside from the bank examples, that I have never personally been involved in any way, I have to see a system that can survive several years between versions without requiring some amount of patching/upgrading/care.
Even big $$$ systems like Oracle RDBMS, MS SQL Server, big Unix/linux deployments require some amount of work in order to upgrade existing apps to new versions of them. Anyway if you have an app that is so important to be running flawlessly over the years and have no chance for failure then you have the $$$ to maintain it that way, either by you yourself patching the old version so that remains useful to you or by extensively testing the old app in the new version. That is something that banks have, that is sure. And that is something that any FOSS project almost never have. Even Red Hat (with corporate $$$) or linux kernel (with tons of developers paid and pro-bono) can't. They sometime have to let behind some release and concentrate effort in new versions and new users. Pay attention that most users doesn't need a 100% backwards compatible platform so there is no reason to slow down or stop improvement for the most in the name of the few. Not that is something personal to the few either. It just a practical issue. Cheers El mié, 27-04-2011 a las 06:10 -0500, Michael Forster escribió: > On Wed, Apr 27, 2011 at 4:47 AM, Marcus Denker <[email protected]> wrote: > [...] > > Yes, using the old version of Pharo that you used when > > you implemented them. > > Like MacOS 9 programs run on MacOS 9. > > > > If you want to run your MacOS 9 Program on MacOSX, there > > is for a time an emulator, and for a time some source compatibility. > > But in the end, the only option is to port. > > > > There is no magic. > > > > You can select between > > > > -> Inventing the Future > > -> Be compatible to the Past at any cost. > > > > If what you have in the Past is valuable, selecting the second option > > makes sense. (IBM, Microsoft). If not, then it's idiotic. > > > > We will improve this a bit in the future, but this is research, so no > > promises. > > > So, we mission-critical users should probably disregard the mission > statement on the web page misleading: > > "... By providing a stable and small core system, excellent dev > tools, and maintained releases, Pharo is an attractive platform > to build and deploy mission critical Smalltalk applications." > > I'm sorry that I don't have time right at the moment to address this > properly, because I do respect the efforts of the Pharo developers, I > fully appreciate the challenges of a FOSS project, and I like some of > the results I've seen (very nice developer UI features, movement > towards announcements, the collaboractive book, and so on). I am > interested, only, in offering constructive criticism, so please don't > mistake my tone. > > The short version of my concern is this: As a "mission critical" user > of Pharo, I will trade backward compatibility for improvement, if, as > you say, you provide "maintained releases". Those last two words are > the most important and incur a great burden of responsibility. I > don't think the Pharo project has fully considered the responsibility > of using those two words. > > The short version of my recommendation is this: Have a look at the > FreeBSD release engineering process. They break backward > compatibility all the time, but, if I have a mission critical > application running on 4.5, I will still get essential bug and > security fixes for a few years, and I can run trials with 8.0 on my > other servers. Moreover, they have an updated documented roadmap that > I can look at to determine that I should continue to run 4.5 on that > one box while testing 8.0 on the others. > > > Best regards, > > Mike > -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
