opnsense-plugins/Templates/version

{
    "product_abi": "%%PLUGIN_ABI%%",
    "product_arch": "%%PLUGIN_ARCH%%",
    "product_conflicts": "%%PLUGIN_CONFLICTS%%",
    "product_email": "%%PLUGIN_MAINTAINER%%",
    "product_hash": "%%PLUGIN_HASH%%",
    "product_id": "%%PLUGIN_PKGNAME%%",
    "product_name": "%%PLUGIN_NAME%%",
    "product_tier": "%%PLUGIN_TIER%%",
    "product_version": "%%PLUGIN_PKGVERSION%%",
    "product_website": "%%PLUGIN_WWW%%"
}
Framework: support version meta data JSON file 2021-02-04 16:58:17 -05:00			`{`
			`"product_abi": "%%PLUGIN_ABI%%",`
			`"product_arch": "%%PLUGIN_ARCH%%",`
plugins: add conflicts to #4202 In order to devise a plan to cope with plugins that deinstall other plugins the best approach seems to be to simply tell the core that other plugins are conflicting. We already have that information so we just have to pass it along. It's a bit similar to pkg and ports where this information is available during build but not used later during runtime. Conflicts are based on installing the same file, but pkg only notices this when it starts installing and will try to tell you again, but it could have already kown. Needs some glue in core as well but it will be very cool. 2024-08-27 02:57:45 -04:00			`"product_conflicts": "%%PLUGIN_CONFLICTS%%",`
Framework: support version meta data JSON file 2021-02-04 16:58:17 -05:00			`"product_email": "%%PLUGIN_MAINTAINER%%",`
			`"product_hash": "%%PLUGIN_HASH%%",`
			`"product_id": "%%PLUGIN_PKGNAME%%",`
			`"product_name": "%%PLUGIN_NAME%%",`
plugins: annotate support tier levels in plugins PR: https://github.com/opnsense/core/issues/5983 2023-01-18 08:57:05 -05:00			`"product_tier": "%%PLUGIN_TIER%%",`
Framework: support version meta data JSON file 2021-02-04 16:58:17 -05:00			`"product_version": "%%PLUGIN_PKGVERSION%%",`
			`"product_website": "%%PLUGIN_WWW%%"`
			`}`