CRD has both `status.sourceType` (singular) and `status.sourceTypes` (plural) with no deprecation notice on the redundant field

[Shreya2005-2005]

The Application CRD exposes two parallel fields in status for tracking source types:

• status.sourceType — a single string, used for single-source applications
• status.sourceTypes — a string array, used for multi-source applications

Neither field has a deprecation notice, no documentation explains which field takes precedence, and there is no guidance on which field tooling should read. This causes real breakage — for example, tools like argocd-image-updater break on multi-source apps because they read sourceType (singular) but find it empty, while sourceTypes (plural) contains the actual data.

The same inconsistency exists in spec with source vs sources and status.sync with revision vs revisions — but those pairs at least have documentation. The sourceType/sourceTypes pair has none.

To Reproduce

Run against any cluster with Argo CD installed:

kubectl explain application.status.sourceType
kubectl explain application.status.sourceTypes

Output:

FIELD: sourceType
DESCRIPTION:
SourceType specifies the type of this application

FIELD: sourceTypes <[]string>
DESCRIPTION:
SourceTypes specifies the type of the sources included in the application

Neither field references the other. No deprecation. No guidance on which to use.

Expected behavior

One of the following:

1. status.sourceType is marked deprecated in the CRD schema with a note pointing to status.sourceTypes
2. Documentation explicitly states which field tooling should read and under what conditions
3. A single unified field handles both single and multi-source cases

Version

argocd: v3.4.1
BuildDate: 2026-05-06T07:49:34Z
GitCommit: bafd59b
GitTreeState: clean
GitTag: v3.4.1
GoVersion: go1.26.0
Compiler: gc
Platform: linux/amd64

Logs

Not applicable. This is a CRD schema documentation/design issue.