I am running on Floating License Software 2.10 for Win, but there is a discrepancy in the vendor's version as shown in the log below and I cannot install the software.
> 11:01:46 (INTEL) Request denied: Client: foo@hoge (11.17) newer than Vendor Daemon (11.16). (Version of vendor daemon is too old. (-83,21049))
the Support Team, on each Update, generates a Closure Report that lists all Online Service Center issues and Forum issues fixed. We then notify those customers with open issue that a fix is in the release and we confirm and close the issue. If you do not get a notification then your bug was not fixed in this update.
Also, updates tend to be only "safe" fixes, nothing that can possibly affect stability. Major fixes go into the next major version, which is 2021.1 that is in beta in the oneAPI HPC Toolkit . Ifort 2021.1Beta for example has F2018 completed.
The IFORT team has been putting most of our efforts into the 2021 compiler which is due to release before the end of 2020.
Ronald, thanks for the reply. I understand what you have said but the flaw is that more than one customer is often affected by a problem but maybe only one files a ticket. I would not file a ticket for a issue that I can see has already been raised and is discussed on the forum. It seem onerous to expect me to file tickets in this instance. It has been discussed many times before, a list of issue number or forum topics would be a step forward. We used to get that in the past. Regards Andrew
I've written a LOT of release notes over the years. In many cases it's hard to write a description that will help someone else recognize a problem. Many of them would be of the form "Resolves a problem where certain combinations of X, Y and Z lead to an internal compiler error." I do think that lists of bug fixes serve a purpose, and was disappointed when they were discontinued, but I don't think they are as helpful as many seem to think.
What tends to happen instead is that someone thinks they have "the same" problem and then complain when it isn't fixed for them. There can be multiple bugs that, on the surface, look the same but a fix for one doesn't fix the others. This is why I always encourage users to submit bug reports and include. not only a small reproducer, but also the full test case. Often the full test case reveals a different problem than the small one.
Andrew is absolutely right on this, the lack of details is highly detrimental to Fortran customers in more ways than one.
Consider this link for Intel IPP: https://software.intel.com/content/www/us/en/develop/articles/intel-ipp-2018-bug-fixes.html
The very premise submitted bugs for Intel Fortran cannot have a consistent tracking # and a brief title and there cannot be a listing of fixed bugs doesn't wash with me at all.
Such a HTML is something that can even be autogenerated based on the simplest of a bug tracking system - even a basic Excel spreadsheet - that involves just 2 steps: 1) an entry when the user reported issue is accepted as a bug by Intel support and 2) marking it as fixed when the compiler team thinks the resolution is included in an update - this is the time when @Ron_Green feels notification emails are sent out to individual customers.
It is always interesting to see the comments that are returned about documentation.
No matter what you do, it is never enough and people will read really weird things into directions.
In my Fortran Water Supply program, large part due to mecej4, the coordinates are input as metres, so I showed the students how to get the lengths from Google earth. They input the lat and long instead of the distances, I had never thought of that and it took me a couple of hours to work out where the numbers came from. The students do things you can never expect.
We assume to much as the release notes show, but can I say the Windows Preview Release Notes do not make much sense.
John, I am really not sure I get what the point is that you are making.
It do not install every Fortran Update, it takes time and effort and may have regression bugs. I do look at release notes for new updates to asses if the benefits outweighs the cost/risk. That is why decend release notes are useful.