Prtg Changelog

[Young Vadlapatla]

Wewould like to have way to receive notifications if an update for the PRTG Network Monitor application is available. This notification should also provide a link to the changelog containing the details the new version.

We are an MSP that manages different applications which are used by our teams to provide services to customers, one of these applications is the PRTG Network Monitor. We run PRTG on multiple servers. One of our recurring operational tasks is updating the PRTG Network Monitor application whenever updates are available. Since updates cause downtime we run updates in a maintenance window, which involves planning and notifying stakeholders that updates will take place.

Currently we manually check whether or not an update is available and then start the rest of the update process. In order to (automatically) streamline this process it would be helpful to receive a notification that an update is available, this also helps us to start the process as soon as an update is available. In some cases we have to check this daily because we are waiting for an update/hotfix to be available which fixes an issue on of our teams/customer is facing.

We have a Microsoft Teams channel that we use to receive notifications on new software updates from different vendors for the applications we manage. The methods we currently use to receive these notifications in the channel are the following:

We would like to receive a message in this channel as soon as a new PRTG update is available. The reason why this is important to us is that we we first of all want to receive notifications of a new available version for business critical applications on a single location, rather than having to (manually) check if new versions are available for every application separately using separate tooling.

We have had contact with the support team where we have asked if there is a possible solution available. They indicated that there is an option we can use, which is to use the ticketing system within PRTG.

Their suggestion was to adjust the following in "Setup -> Auto-Update -> Settings":- Automatically download and install the latest version- Automatically download the latest version and alert the admin- Alert the admin only

After some in depth trace log performance analysis both server and client side using the PDT tool, customized and vanilla, I have identified that specifically enabling the change log on the orderhed table absolutely TANKS performance on the sales order master update method when there are 30+ lines.

Logging: Build upon the current system to log the same fields for adding records and deleting records. Record the fields that are records for changes. Possibly, expand the logging system to also record changes to an external logging process...

We had everything on the sales order detail being logged (including the sysrev ids). This kept causing a long running SQL transaction. We were able to identify the query (the ice.changelog was in play). Because the transaction for the change log table was running for 2 days our trans log backups were not occurring.

Another Great Tool if you want to understand Epicor is:

SQL Data Compare: Compare And Synchronize SQL Server Database Contents - you could take a backup, run MRP and then compare your backup to your database and see all the tables an MRP run affected.

I want to get some Nagios/Centreon open source monitoring set up for us on-prem so I can monitor all critical epicor services / the task agent schedules to see if they get backed up / automate and monitor and execute DMT jobs. Soo much cool stuff.

When people upgrade from one version to another, it should be painfully clear when something will break. It should be possible to upgrade to a version that lists deprecations, remove what's deprecated, then upgrade to the version where the deprecations become removals.

Regional date formats vary throughout the world and it's often difficult to find a human-friendly date format that feels intuitive to everyone. The advantage of dates formatted like 2017-07-17 is that they follow the order of largest to smallest units: year, month, and day. This format also doesn't overlap in ambiguous ways with other date formats, unlike some regional formats that switch the position of month and day numbers. These reasons, and the fact this date format is an ISO standard, are why it is the recommended date format for changelog entries.

It's a great initiative. Releases can be used to turn simple git tags (for example a tag named v1.0.0) into rich release notes by manually adding release notes or it can pull annotated git tag messages and turn them into notes.

GitHub Releases create a non-portable changelog that can only be displayed to users within the context of GitHub. It's possible to make them look very much like the Keep a Changelog format, but it tends to be a bit more involved.

The current version of GitHub releases is also arguably not very discoverable by end-users, unlike the typical uppercase files (README, CONTRIBUTING, etc.). Another minor issue is that the interface doesn't currently offer links to commit logs between each release.

Yanked releases are versions that had to be pulled because of a serious bug or security issue. Often these versions don't even appear in change logs. They should. This is how you should display them:

3a8082e126