Ensure consistent usage of renderVersionBadge

[PyvesB]

The following function was introduced in #1922:

shields/lib/version.js

Lines 144 to 150 in 302c860

	function renderVersionBadge({ version, tag, defaultLabel }) {
	return {
	label: tag ? `${defaultLabel}@${tag}` : undefined,
	message: addv(version),
	color: versionColor(version),
	}
	}

We should be using it where appropriate.

See #1965 (comment).

[paulmelnikow]

Mostly done in #1998, though we need to tackle it for f-droid.

To expand on this a little bit: I'm thinking we should make a pass through all the new-style services for consistency of style. Having a consistent style in place means contributors will refer to code that are exemplars of what we want, minimizing the amount of "please make this more the way we want it," and creating a more positive contributor experience.

It seems a little fussy to do this on existing code which is "good enough." However, I think more positive contributor experience is a good reason to make the extra effort up front.

What do you think about that idea?

[PyvesB]

Yes, I think going through all our new services to make sure the style is consistent would make sense.

[chris48s]

I don't want to get too "philosophical" about this, but I've been having a bit of a think about this while working on PR #2086 I've left some inline comments there, but in general I think we need to be quite careful about trying to bash every peg into the same template. These helper functions are informed by particular world views e.g:

• packages use SemVer or some SemVer-like schema, or
• permissive licences are "good" and copyleft licences are "bad"

These world views don't necessarily map well onto all programming communities. For example, there are some programming communities where a lot of projects use alternative versioning schema like CalVer or just don't specify any particular way of versioning.

Similarly there are some programming communities where it is not really appropriate to try and assign meaning to licenses via colour, or where a license is "good" or "bad" may not be about permissive vs copyleft but more about whether it is "GPL-compatible" (which is a property that can apply to some subset of both permissive and copyleft licences) for example.

I'm not saying these helpers aren't useful code - they are and we can use them to reduce duplication in many places, but I do also think we need to be careful about pursuing standardisation within our own codebase over embracing the norms of the programming communities our output is going to be used in. I accept this can also be quite a difficult thing for us to do because often we're working on code from the perspective of outsiders to the community it will be used in.

Something to think about anyway..

[paulmelnikow]

For example, there are some programming communities where a lot of projects use alternative versioning schema like CalVer or just don't specify any particular way of versioning.

👍

Let's rename the helper so it's clear it's intended for communities which use semver, or better yet, add a usesSemver parameter to it.

Similarly there are some programming communities where it is not really appropriate to try and assign meaning to licenses via colour, or where a license is "good" or "bad" may not be about permissive vs copyleft but more about whether it is "GPL-compatible" (which is a property that can apply to some subset of both permissive and copyleft licences) for example.

Are there any programming communities where copyleft is seen radically differently from others?

By choosing orange for GPL I've tried to sidestep the value judgement. I've wandered from one of these schools of thought to the other in the last 10 years, and tend to think folks who like GPL can train themselves to look for orange license badges, likewise folks who like permissive licenses and green.

Alternatively, perhaps we could try to refine the colors.

I participate in more than one programming community and FWIW I'd find the consistent colors helpful.

This overlaps with #1093; going to close that so let's wrap up this discussion here.