I don't want to get to deep into issue, but ... I think ISC (and many other companies) have been somewhat flaky about how they designate releases. Their desire to meet customer needs creates a steady stream of release upgrades. While it is not a hard and fast rule by means, generally we saw the following in the past with business software of all kinds:
- full number releases (5.x to 6.0), typically involve major changes/improvements including new features - .n releases (5.0x to 5.1) add minor features and bug fixes. -.x.n releases (5.0.11 to 5.0.12) denote changes made to fix existing problems. Upgrading from 5.0.10 to 5.0.11 should be a no-brainer. Adding new features to a maintenance release should not cause new problem. Otherwise, they should be clustered and released as 5.1 By the time 5.1 actually ships it will be a de facto 6.0 release. What we have here a something of a numbers game. In large organizations (especially governmental) release numbers are taken very seriously. Moving to an new full number release upgrade requires a huge amount of analysis and can, typically, introduce consideration of competitors. There are some famous examples of this. WordPerfect 4.1 to 4.2 was a major upgrade. But the company called it 4.2 instead of 5.0 to avoid the approval cycle. As time went on, the release numbering was controlled by the marketing department instead of engineering. The same is true to lesser extend for .n upgrades, indeed, any changes. Is there a solution? I don't think so. A measure that would be helpful would be an advisory as to WHO should perform an upgrade and WHAT they may expect. Even with ad hoc patches, a maintence release should not cause problems. On the other hand, all these updates and patches are the result of a service-oriented, technology-driven approach from ISC that has served us well for years. Maybe I should focus on something less controversial like the race for Warlord of the USA. jb "Ram�n Jim�nez" wrote > > > And I was happy that ISC finally decided to restrict themselves to bug > > fixes in MAINTENANCE releases. The v4.1.x releases were far too unstable > > to simply install them without significant testing by us as too often > > new functionality that was developed in the V5 code base was simply > > backported without much QA. > > Certainly this is a difficult issue. > > I don't quite remember the 4.1.x releases, sorry about that - but if you > look at 5.0.0 and say 5.0.4 we're talking about very different beasts. > Mostly thanks to "little things" like scrollable result sets, better > system task scheduler, etc. > > Now with 5.0.11 I feel we could get a good feature that should not wreak > havoc on pre-existing functionality... Albeit I still believe it's not > worth it to try to do Web development without re-painting the entire > page, but for people who like #server()# this means "less" moving parts, > if only because of the whole Sun/Microsoft affair. > > Then we have Peter's opinion - adhoc patches and the need to show > something because 5.1 is *so* late. And that precisely is my point, > which is not so different from yours when you think about it: > > - Release x.y.z comes out > - There is something you want to do which is not implemented yet > - You resort to a temporary kludge until x.y.z+1 comes out > - But your new feature won't be out until x+1.y.z > > The last three major Cach� releases (3, 4, 5) have brought immense > changes with them. This means that few shops are willing to deploy the > ".0.0" releases. Given that those releases are coming out later and > later, this means that major improvements are being significantly > delayed. One year between releases, plus a couple of months before early > adopters iron them out, plus like you say a couple more months to do > in-house testing and planning the migration... Eventually, you are only > getting new features every two years or so. > > I understand ISC has limited resources and I don't demand faster > releases, especially if it compromises quality. But I *do* prefer better > spread releases, more sensible release plans. I guess this falls in line > with an old complaint of many people here in that we seldom have a clear > idea of the release plan - bad for long term planning. Sometimes I guess > they just like to grab too much in one bite (or something to that effect...) > > And don't even get me started with the whole 5.1/6.0 thing. In my mind > it is cleary a 6.0 release, and the delays are but a sign of it. > > Cheers :) > > Ram�n > > -- > ZCacheLib - Open Source Extensions for Cach� > http://www.zcachelib.org
