While that is great news if the issues are resolved daily the fact remains we don't see the fixes in the product until a patch is released which isn't daily.

In all honesty I don't care when an issue was resolved. I only care when the resolved issue iwas included in a patch release.

for example Casual view does not save ID in the change log for Single Instance tables. ASI might very well have it resolved today but if I have to wait for a new patch then does it matter if ASI resolved it today, tommorrow or 5 minutes before the patch was released.

I don't go check the update on all my issues on a daily basis. not sure who actually has time for that. When a new patch comes out I read the Release Notes and review the issues it has resolved. If none of the issues I have is resolved then I typically don't bother installing the patch.

I now have lost that ability.

JB, you hit it on the head. We absolutely depend on the list of items fixed in each release. Fixes in internal RC releases are nice -- we're glad the product is getting fixed -- but pretty useless to those of us in the field.

Release notes are the only information we have about fixes reported by other AiSPs or discovered internally. Many times, we don't even know about a bug in a particular version until it is described in release notes for a later version. That's another sore subject, but I won't go into that now.

The point is, we already feel like we have barely enough information to help our clients. Release Notes have been our best source of information up to this point. Taking away the release notes is a big problem.

Here's how I think release notes should work.

• If a problem was fixed anywhere between two consecutive releases (RC, GA or patch), it must be included in the release notes. (Mandatory)
• Fixes included in Release Candidate releases need to be rolled up into the GA release notes. It's insane to review the release notes for an unsupported RC to know what has changed in the supported GA. (Mandatory)
• Release notes for patch releases should include all fixes since the last GA. (Important and a huge time saver, but not mandatory)
• Release notes for a new GA release should identify what patch of the previous version it is relative to. Usually this would be the last patch, but every now and then ASI releases one more patch after the new GA (timing issues or critical problems). (Important)
• Having a place to find every fix between two arbitrary versions is a nice-to-have. We can get this by pulling the GA release notes and the latest Patch release notes for each GA. (Important)

-- Bruce

The point is we always have had the 'Resolve Issue' site where we can search on and always had the 'Release Notes' PDF.

Because they co-existed for a long time. I am not really buying the argument that the 'Resolve Issues' page serves the same purpose of the 'Release Notes' PDF because if that was truly the case why did they co-exist for as long as they did.

My argument is they co-existed because they served two different purposes and functions. When one of them no longer exists. An effect to replace the functionality needs to be made.

I will be perfectly happy if the 'Resolve Issue' page was redesigned to better navigate and the description and resolution fields were cleaned up. then you can make the argument that the functionality of the 'Release Notes' PDF is now a part of the Support site.