What's the point of

documentationUrl

in source/destination destinations?

The spec command is already expected to return a real documentation URL.

Everything is set to something like https://hub.docker.com/r/airbyte/integration-singer-csv-destination

which isn't used anywhere or particularly useful (as far as I can tell)?

If it is used somewhere, shouldn't it use what the spec is returning instead?

That’s intended to be the URL pointing to available image tags in the Admin UI

and change log

there's no repo overview there though

and changelogs would presumably be in the root airbyte project?

And can't tags be inferred from

airbyte/integration-singer-csv-destination

alone and the default registry?

tags meaning all available tags

For the consumer to find

Why would a user go to that link to look for tags?

we can determine what the tags are but it’s supposed to give an easy way for them to find out what tags exist. The missing piece is a change log. imo we should put changelogs in the root repo and then maybe change these urls to point there

I thought the UI would automatically show available tags?

It doesn’t do that at the moment

ah

so are we expecting to maintain up to date descriptions of each point version of integrations?

if so that seems like it should exist in the same format as the source definition with some additional metadata for that version

if we need a programattically accessible changelog

so are we expecting to maintain up to date descriptions of each point version of integrations?

only in documentation at the moment

basically a change log

I'm still a bit confused how this helps a user select a tag they want

wouldn't they always want latest unless they wanted to revert after upgrading?

I can't imagine consciously choosing a specific older version otherwise

assuming airbyte ships with the latest versions, this means people running airbyte instances would need to manually upgrade their connectors

so you only upgrade when you specifically choose to

is the concern that this is the intended behavior, or that the UX doesn’t help the user navigate it?

I definitely think the latter is true right now

I agree you should only upgrade when you choose to, but people would generally upgrade from current to latest if they want to upgrade

the UX doesn't seem to help and the changelog won't help either if the pattern I'm describing is the primary use case

upgrading to latest?

yeah

I don't think people will search through a changelog looking for the feature they wanted

and upgrade to that

vs going to the latest that also includes the feature they wanted

right so in that case the user upgrades to the latest version

unless you mean

latest

seems like it'd mostly be bug fixes or changes to the underlying integration

which is undesirable

yeah I mean latest as in highest semantic version, not

latest

tag

I'd prefer to have global airbyte changelogs instead of integration-specific ones

wouldn’t having a changelog help them figure out the latest version if they don’t care to comb through every line in changelog?

ah

Just due to ease of management