There’s not usually a FP/CF/etc. update for an initial .0 release, except waaaay back in R5 (5.0a was released).
We never see fix packs until after the .1 or .2 release of a major version. Can somebody explain why this is? I’m just curious.
In 8.0 the first FP was 8.0.2FP1 – were 8.0 and 8.0.1 so solid that it didn’t need them? What about 7.0? 6.0, 6.5, and 6.5.1 didn’t have them either.
Subject: Fix pack Response
Hi Erik,
Thank you for asking this question. I’ll start off with the positive news that we are planning and working on an 8.5 Fix pack 1 right now. It is planned for server and client, but we have a lot of work to do before we will be ready to give a solid date. Right now it’s looking like late Q2 2009. Ideally it would be sooner, but we have some technical hurdles to address in the install technology.
The primary reasons for not generating a fix pack on a .0 release historically centers around 2 things:
The time frame to the first maintenance release after a feature release ships
The number of issues that we need to address.
The time frame to the first MR is (usually) fairly short and we are able to get more issues addressed in a maintenance release than we can in a fix pack. The length of time between 8.5 and 8.5.1 is long enough, and the quality we believe is high enough, that we should and can release a fix pack that focuses on the right issues earlier than waiting for 8.5.1.
Stay tuned as we identify the issues to address and finalize the release schedule.
In the meantime, I would like to point out that burning issues that we need to get out to our customers even before a Fix Pack is available, will be delivered as interim fixes through the Fix central web site. The following 8.5 interim fixes are currently available:
Domino: 8.5 Interim Fix 1 fixing this issue
Notes: 8.5 Mac Interim Fix addressing these issues
A schedule for 8.5 Fix Pack 1 and a preliminary list of issues to be addressed will be posted to our fix list database once we have the information.
Regards,
Scott Vrusho
Sr Dev Manager, Notes/Domino Maintenance & Service Planning
Workplace, Portal and Collaboration Software
IBM Software Group
Direct line: 978-399-6418, TL: 333-6418
Notesmail: Scott Vrusho/Westford/IBM
Notesmail:Internet: scott_vrusho@us.ibm.com
Subject: Thanks for the response, Scott.
It definitely makes sense, and I’m glad to hear that there’s a potential 8.5.0FP1 in the works – it sounds like there are a few significant issues with 8.5 that would be of great impact to customers.
One of the main reasons I ask is that the very decision of IBM/Lotus committing to a Fix Pack opens up an extremely useful avenue for customer testing: the Fix List database.
For example, 8.0.2FP1 addresses several regression bugs in 8.0.2, 8.0.1, and 8.0. During the development of 8.0.2FP1 those SPRs were gradually added to the Fix List database, and so those of us testing 8.0.2 (or an earlier version) could try to specifically test against those SPRs to determine if we may need the FP or a hotfix.
Subject: My best guess
I’m not in support, but this is my experience the last few cycles:
The .1, .2, etc., releases are now on a three-time-a-year cycle (used to be quarterly), and address a whole host of issues that came up since the initial .0 release. These are cumulative, and can have several hundred fixes in them.
Fixpacks are meant to come out between these cycles, and are much smaller in nature, but are tied to a specific release. In other words, 7.0.2 had 1,249 fixes and could be applied to 7.0.0 or 7.0.1, but FP1 for 7.0.2 could only be applied to 7.0.2; hence, FP1 had only 29 fixes.
As to whether or not a FP gets released, that’s really up to development. If there are several issues that affect enough customers (esp. large ones), a general-purpose FP will be released. If there is a specific issue that you need fixed, support is very good about providing either a workaround or a hotfix for your environment.
Subject: My point is we can wait for MONTHS before knowing about an SPR that might be ultra-important
My main point was that, as a customer, you get access to some SPR knowledge earlier if there are Fix Packs being constructed.
For example, unless there’s a FP being made for 8.5.0, we won’t know about any known SPRs for it until 8.5.1 starts becoming populated in the Fix List database. Since 8.5.1 won’t be out until August at the earliest, we won’t see those SPRs until likely May/June at the earliest.
So for at least 5 months we’ve got 3 options:
Search for known SPR #s here
Hope we find any pertinent problem during testing. Then we have to open support tickets and support has to ID the problem (which means THEY’VE got to find the SPR #). If there’s a hotfix, great, if not then then we have to decided if it’s a ship-stopper on our end.
Discover a problem after rollout. Then we have to open support tickets and support has to ID the problem (again, they’ve got to find the SPR #). If there’s a hotfix, good, but now we’re talking about bringing production servers offline. What’s worse is if there’s NOT a hotfix, in which case we have to decide if now a rollback is necessary.
I’ll agree that support is generally very good about hot fixes.
But if we at least had access to a list of known SPRs for 8.5.0 sooner then we could specifically test against them, helping us to open support tickets in scenario #2 as opposed to scenario #3.
This is especially important with .0 releases, since they are usually major upgrades with NAB view changes, etc.
For example, I’ve learned through this forum that 8.5.0 has several problems. Just off the top of my head:
LS debugger sometimes doesn’t work
Designer is crashy
DAOS bombs with high-strength encryption
Adminp crashes (yes, this was addressed in HF1, but that’s not listed in the Fix List database either. It’s a “must have” I would think.)
Here’s a better example:
Just today it looks like a “ship-stopper” from 8.0 (that was fixed in 8.0.1) has regressed in 8.5.0:
I hope that people catch this one during testing. If not, OUCH.
The problem will be SPRed if somebody reports it, but the rest of the world won’t know unless/until it gets triaged into an FP and updated in the Fix List db. Until that point us AND Lotus support are wasting a lot of everybody’s time.
Subject: Technotes are also a good avenue
Defect reported via support, make it into technotes so customers are aware of the issue sooner rather than later.