Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: Standardize Output Parsing for Application Attributes #731

Open
2 tasks done
ricoroodenburg opened this issue Aug 13, 2024 · 4 comments
Open
2 tasks done
Labels
enhancement New feature or request

Comments

@ricoroodenburg
Copy link
Contributor

ricoroodenburg commented Aug 13, 2024

What is your feature request?

Currently, there is inconsistency in the naming conventions used for application outputs, such as "Ring," "Stream," and "Channel.". For example, Citrix uses "Stream" (e.g., Current), while Microsoft uses "Channel" (e.g., Current).

To improve clarity and consistency, I propose that we standardise all these terms.

Below is the proposed standardised set of attributes:
Name: The application's name.
Architecture: The system architecture (e.g., X86, X64, ARM64).
Installer: Previously referred to as "Type." This could include formats like MSI, EXE, and MSIX.
Edition: Previously referred to as "Type," "Plugin," or "Release." Examples include Enterprise, Reader, Acrobat.
Channel: Previously referred to as "Ring," "Channel," or "Stream." Examples include Current, Production, Public.
Language: The language of the application (e.g., EN, NL).
Date: The date when this version of the application was released.
URI: Download URI
Version: The specific version of the application.
Build: The specific build of the application.

Have you tested against the current version?

  • Yes, I've updated Evergreen and tested against the current version.

Have you reviewed the documentation?

@ricoroodenburg ricoroodenburg added the enhancement New feature or request label Aug 13, 2024
@aaronparker
Copy link
Owner

I've been considering this as well - standardising on the properties would make sorting output more predictable.

How to update these is a consideration - all in one go, or app by app?

@AScott-WWF
Copy link

I like this as an idea in principal, although there will inevitably be apps where vendors don't supply all of this data, so I guess there should be a core set of 'required' attributes and the rest are optional.
Example: If an app's language is not publicised, should it be assumed (defaulted) as en-us, en-gb (or en-au for you benefit @aaronparker 😂) or simply not set?
Release Date is one that is really useful, if the vendor publishes this, use their date, if they don't publish the release date as the first time Evergreen detects it as available?

Suggested Required attributes for each app:

  • Name
  • Architecture
  • Installer
  • URI
  • Version

Optional:

  • Everything else

N.B. I personally would prefer this change to be rolled out on an app-by-app basis over time, as this should reduce the work load of having to update all my scripts in one go that depend upon Evergreen - If they are all done in a big bang, I could have a few days where my workflow ceases to work.

@aaronparker
Copy link
Owner

Architecture can be difficult sometimes - that info is not always provided where there is a single installer returned.

@aaronparker
Copy link
Owner

Many of the properties names/values used in the current apps has been based on the properties provided by vendors - some vendors might refer to different names for what is essentially the same property. E.g. Channel or Release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants