Clearly label or group together obsolete/deprecated/legacy features

A similar thing should be done for plugins that are dedicated to migration, namely AF Link and Security Settings. The other purpose of both suggestions is to gamify the migration to newer features. If you have a group of plugins labelled "Legacy" or "Migration", that is a constant reminder that you still have work to do on your PI system. The goal would be to get to a point where you can safely hide all of the plugins under these groups. A group is not hidden unless all of its plugins are hidden.

This becomes unclear when you have a newer version of PI SMT being used against an older version of the Data Archive. Obsolete/deprecated/legacy features are version dependent. It is deceiving to say something is deprecated when in fact it is not, based on the Data Archive version. As such this becomes tricky if you manage a fleet of Data Archive with varying version/vintage.

Stephen, can you give me a specific example of a case where the version dependence of the deprecated/legacy label is actually worth working around? I would argue that the label of deprecated/legacy is dependent on the current versions of PI SMT and the PI Data Archive. I think that it is OK for a feature to be labelled as deprecated/legacy even if PI SMT is being used on a version of the PI Data Archive that does not support the successor. It's about letting the user know which features they should and shouldn't be using. Also, for security and stability reasons, the user should be trying to upgrade all of their PI programs every so often anyways, so I feel that OSIsoft shouldn't work around those that haven't upgraded in forever and send the wrong message that it's OK to do that. Since I have learned more since the time that I posted this suggestion, I can be more specific with it. I will be using my blog post (https://osisoft-ext.jiveon.com/people/Kenneth_Barber/blog/2020/11/23/a-modern-walkthrough-of-pi-system-management-tools) as a reference. Migration plugins: • AF Link • Security Settings Deprecated/legacy plugins: • All of the plugins in the following groups: Alarms, Batch, Interfaces (maybe), IT Points • Module Database (maybe) • Reason Tree • Performance Equations • Totalizers Also, consider splitting the following plugins into 2 and include the deprecated one in the list above: • Database Security → Legacy Database Security (contains PIAFLINK (maybe), PIBatch, PIBATCHLEGACY, PICampaign, PIHeadingSets, PIModules (maybe), PITransferRecords, and PITRUST) + Database Security (contains whatever remains) • Identities, Users, & Groups → Identities + Users & Groups • Mappings & Trusts → Mappings + Trusts For other deprecated/legacy features, I felt that clear labelling was not the right solution, hence the suggestions below: • https://feedback.osisoft.com/forums/555148-pi-server/suggestions/40282513-remove-the-pi-interface-configuration-utility-pi • https://feedback.osisoft.com/forums/555148-pi-server/suggestions/41967757-by-default-do-not-install-the-pi-module-database • https://feedback.osisoft.com/forums/555148-pi-server/suggestions/42024571-by-default-hide-the-tuning-parameters-of-legacy-f I think that that covers most of the deprecated/legacy features. Let me know what you think.

Perhaps I was not clear before. We have customers using mixed versions of PI System software, ranging from Data Archive to interfaces to client tools, etc. Unfortunately not everyone is on the latest version, despite that's our recommendation. Customers don't always upgrade to the latest version for various reasons. It maybe because they have a special 3rd party interface or component that they cannot upgrade, or perhaps it's cost. Regardless, if a user starts up a new version PI SMT and connect to an older version of Data Archive, say 2010, and SMT shows that Performance Equation is deprecated. That's incorrect as the 2010 version of Performance Equation was not deprecated when it was installed. In short, they are not using a deprecated version of PE that was installed with Data Archive 2010. Worst yet, this change would manifest itself on the client side when the user simply changes from an older version of SMT to a newer version of SMT, which of course has nothing to do with PE on Data Archive 2010 (using this example). This is an example scenario of what I was trying to convey previously.

Stephen, I understood you correctly the first time, and I still understand you. You view deprecation as a status that depends on version. I view it as a status that depends on time. The difference is that you can use an old version, but you can't live in the past and so you can't live in a time before a feature was deprecated. Under your reasoning, as long as something was not deprecated at the time that you bought it, then it is not deprecated. In that case, Windows 98 on my family's old laptop is not deprecated. Using that logic, nothing is deprecated unless you upgrade to a version that tells you so. In your example, if a user upgrades their version of PI SMT, causing Performance Equations to be lumped into the legacy/deprecated features despite no changes being made to the PI Data Archive, I think that that's OK. That is what my suggestion is asking for. To me, it says that, at the time of the release of their old version of PI SMT, Performance Equations were not necessarily deprecated, but at the time of the release of the new version of PI SMT, Performance Equations were already deprecated. If you take a version-based view of deprecation, then, as you mentioned, PI SMT will no longer accurately reflect that version of the PI Data Archive. If you take a time-based view of deprecation, everything makes sense. I'd like to think that most people use the time-based interpretation.