Migrate from latest to a versioned release scheme

[muuki88]

Currently PUC guarantees 100% backwards compatibility for eternity due to the fact
that an unknown, but properly huge portion of publishers use the latest.js PUC script.

This means that every change in PUC must not break any existing integrations, which comes at a cost

• no removal of old, maybe unused code. Technical debt grows unhindered
• extensive testing as revenue for publishers for all over the world are at stake

@dgirardi already made a good proposal in this comment

Brainstorming ideas on how to escape this trap, we could try to tie breaking changes to Prebid major versions; the transition will take forever, but we could for example ask pubs to set up

<script src="https://cdn.jsdelivr.net/npm/prebid-universal-creative@%%PATTERN:hb_ver%%/dist/creative.js" />

and start a new PUC branch (and release tag) for each new Prebid major version.

I would like to extend this proposal a bit and elaborate why.

Proposal

TL;DR: The general idea from @dgirardi remains the same. A key value can be used to determine the PUC version, but it's configurable in prebid.js with a sensible default.

Background

We are currently using a fixed version like this

https://cdn.jsdelivr.net/npm/[email protected]/dist/creative.js

and upgrade creatives when we see a necessity. A fixed identifier comes with the benefit of

• full control over the deployed version
• better caching

Upgrades are done via the GAM API, which many publishers don't have the resources to integrate.

Configurable PUC version in prebid

If the PUC version would be configurable inside prebid with something like

pbjs.setConfig({
  puc {
    version: "1.13.0"
  }
});

this would allow us to

• release new PUC versions when we want without any publisher using it
• provide a sensible default in prebid.js, e.g. when a new PUC version is deemed stable, Prebid.js uses this as a new default
• brave publishers can point to a newer version earlier to test things

The puc.version property would be set as a targeting parameter. For google ad manager this can be done on a page-level, e.g hb_puc_ver.

[dgirardi]

Thank you for expanding on this! I like the idea of making it a config option, but I have questions:

• should the version be that specific? in contrast with for example 1.13.x (or maybe prebid-7, we'd have to use dist-tags for both so that may be a better name). I'd expect most publishers to want PUC bugfixes without having to make a config change, is that the case?
• if you are not using PUC, we probably don't want to send the extra key-value pair for it, so we need a way to turn it off. Maybe setConfig({puc: false}) ?

[muuki88]

Disabling should definitely be possible 👍

About the version granularity. I really like the idea of having

• Every pull request being merged triggers a release, with a git hash appended to the current version number
• A git tag builds a versioned release

All the decision logic which version is in prebid.

However what this doesn't provide is a mean of hotfixing a specific version. The same is true for prebid. And because the default puc version is configured in prebid, I would argue this is okay.

[dgirardi]

The (possible) issue with that is every pub needs to keep up with which particular PUC version is the "correct" version for their Prebid deployment. It may go too far in the other direction, compared to now where most pubs get all updates automatically. For example:

• pub has prebid version A that defaults to PUC version A*
• we discover horrible bug in PUC A*, release version B*
• pub needs to be aware of the bug and needs to update configuration to point to B* (or update Prebid to a version that defaults to B*)

The alternative would be:

• Prebid version A.x defaults to an NPM tag for PUC A*.x
• Backwards-compatible PUC changes are released with the A*.x tag, and pubs automatically get them
• Pubs can still point to a specific PUC version if they are more comfortable with that.

[patmmccann]

The current proposal is to add a configuration option to pbjs that passes the puc version in ad server targeting and recommend users adjust their puc to stop pointing to latest and use the macro. Each prebid js release would default to point to a particular latest puc release if a publisher is opting into passing that, indicating they use the puc.

[dgirardi]

We should update PUC to pick up the same rendering logic merged with prebid/Prebid.js#10819