Jump to content
Private Messaging is activated - check "How to" on how to disable it ×

Note on the release notes for ZEISS INSPECT 2023


---
 Share

Recommended Posts

Dear Support,


you recently published ZEISS Inspect 2023 SP3 and the associated release notes. In text form, 31 "bugfixes and improvements" are mentioned, whereby the paragraph "Covered cases" only lists 16 corrected errors.


For me as a user and system administrator, this poses several problems:

  • Which case number belongs to which text or bug description?
  • Do some error descriptions refer to errors that I have reported myself? My documents do contain the case numbers for my own error messages, but does an error description in the release notes actually refer to a specific case number that I have reported myself? You can only guess from the text... In any case, a clear assignment is no longer possible.
  • What about the 15 text passages that definitely cannot be assigned a case number from the list due to the lower number of case numbers? Are these all "improvements" without case numbers?


Example:
The text in the release notes mentions two points that have been improved with regard to the grey value feature and mesh adjustment:

  • Polygonise and Recalculate - Gray value Feature (Mesh Adaption):
  • Gray Value Feature (Mesh Adaption) / Height offset

Errors reported by me only related to the V2023:

  • Hexagonal hole "cannot be successfully adapted to the mesh" with VC
  • No mesh adaptation despite closed edge curve
  • Error in the calculation of edge curves/mesh adaptation
  • Mesh adaptation to edge curve is not calculated
  • Error MP "Grey value feature (mesh fitting)" for edge curve (trimming curve)

Does one or both of the improvements mentioned in the release notes affect the points I mentioned? If so, which one? The connection cannot always be clearly established, as the actual cause of the error within the software described in the release notes does not necessarily have to match the customer's own description of a potential error! A customer's error description often only shows certain "symptoms", the software-internal error described in the release notes can be a completely different one, which ALSO leads to the error pattern described by the customer!


A reliable and unambiguous assignment between reported errors and the improvements described in the release notes is only possible via the case numbers! It is therefore essential that these are included in the textual descriptions, if available!
Compared to the release notes for version 2022, the release notes for version 2023 are clearly a step backwards and "system administrator unfriendly".


Please check urgently whether the previous status of the documentation can be restored!
Many thanks in advance!

Link to comment
Share on other sites

  • 2 months later...

The internal discussion does not seem to have led to a more user-friendly error documentation so far. The release notes for version 2023 SP4 are still designed in such a way that fixed errors are listed in text form on the one hand and the numbers of fixed and corrected tickets on the other - but no connection can be established without your own work effort and detective instinct.

Link to comment
Share on other sites

  • 4 weeks later...

Hello,

more detailed release notes are still considered, but will be changed for the upcoming major version. The documentation for 2023 SP4 was not changed.

The release notes for the upcoming major version will not include bug fixes as usual in the last years. A change in the release notes will first have an effect with the first service pack for the upcoming major version. But I cannot confirm yet, that the style of the release notes will change. It is still discussed and considered internally by the teams responsible for the release notes.

Regards
Nanno

Link to comment
Share on other sites

I assume or expect that some bugs from the previous versions have been fixed in the upcoming new major version.

How do you imagine that we customers will be informed about these changes if the first release notes for this new major version do not mention any errors and their processing number? 

Or should all users send their bug lists from previous years to support with the request to report the status of each bug? I don't think that would make sense, neither for your support team nor for us users!

Link to comment
Share on other sites

  • 3 weeks later...
  • 2 months later...

Please sign in to view this username.

 this is indeed interesting that there now is an area to provide improvement feedback ... but Andreas is talking about something that used to be in the release notes and now not there.

This isnt a software feature , it is a documentation downgrade that has happened and hes asking (very rightly) for the older (better) practices to be reinstated. 

Your reply was well intended, but i'm afraid this type of answer is rather poor and unsettling to say the least given the context.

Link to comment
Share on other sites

James has already summarized it correctly: this is not about improving INSPECT, but about improving the documentation regarding the correction of errors in the service packs!

Since working with “GOM ATOS”, “GOM INSPECT” or now with “ZEISS INSPECT”, we have reported over 550 potential errors to support to date. For internal communication with colleagues from the metrology department and for the decision to switch to a certain version/service pack, it is important to know which errors have been corrected (in which service pack or in which main version) or are still contained in the software.

The current status of information for INSPECT users with regard to corrected errors is very unsatisfactory! Either no case numbers are given at all (main version) or the textual information is separate from the case numbers (service packs). In both cases, it is almost impossible to track your own cases and, if necessary, to check them off as completed.

In my opinion, the goal would be to give users access to a specific view of the central error database (or to set up a “customer database” specifically for this purpose) with the option of entering their own case numbers and displaying the status of the error correction. On the one hand, this would relieve the support team of the constant stream of customer queries, and users could get an overview of their own cases at any time.

Link to comment
Share on other sites

Please sign in to view this username.

 

Please sign in to view this username.



I am sorry that you feel like my answer is "rather poor and unsettling."

I understood the issue was with the release notes and how they are presenting the corrected errors now vs how they used to be presented. That your issue was not with something within the software itself.

However, My Voice would still be the correct avenue to voice your suggestion. Whether it is wanting to go back to the way the release notes used to be presented, or if it's wanting to go in a total different direction.   

Developers look at My Voice and take these suggestions into account with what is potentially changed in the future. 

Therefore I stand by my original answer and I would put this suggestion into My Voice. 

Link to comment
Share on other sites

Please sign in to view this quote.

 

I am sure that the developers have enough to do at the moment with looking after our software requirements from the last few years, which have not yet been implemented despite the release of some major versions. :-)

No, seriously aside, I'm certainly not going to enter our requirements into a system that can be publicly viewed by everyone and thus make it possible to observe which topics or problems we are dealing with. We have a well-established process here with support, from which we receive a case number that we can track. Provided the case numbers are clearly itemized in the release notes... ;-)

Link to comment
Share on other sites

 Share

×
×
  • Create New...