Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document since when a particular API / module / config is available ( date and release version) #4558

Open
pm-harshad-mane opened this issue May 10, 2023 · 3 comments

Comments

@pm-harshad-mane
Copy link
Contributor

Our documentation is pretty neat but does not mention when a new config-param is supported by Prebid core / module.
Having this information will help publishers to understand whether the config is supported in their live version...
Without this information, developers need to dive into code to find respective config supporting code.

@muuki88
Copy link
Contributor

muuki88 commented May 18, 2023

That's a very good point. In #4541 I'll collect requirements if we would switch to another static site generator that solves issues that emerged in the past years.

@pm-harshad-mane
Copy link
Contributor Author

Thanks @muuki88

@bretg
Copy link
Contributor

bretg commented Jun 6, 2023

As a bit of cautionary defense - as useful as it might be, curating this information is not trivial. This task falls into the "easier-said-than-done" category. Doc reviewers are going to have to have to have a place to put the info and will need to remember to enforce it. The hard part is that any version placed into the document draft is provisional, and will need to be updated when it's actually released.

If Muki doesn't come up with a better one, here's a suggested approach:

  • when there's a new param for core or an existing component, an expected version should be added to the appropriate table in the description field with an inline note: "DRAFT_VERSION"
  • when there's a DRAFT_VERSION mentioned in a document, a new "needs version" label should be applied to remind the docs team to scan the document and update the version as needed.
  • For Prebid Server and SDK, this will be more difficult because there are two platforms for each which can receive different versions at different times.
  • for every type of file (pbjs bid adapter, analytics adapter, user id module, rtd module) a new "pbjs_version" metadata field. This should hold the PBJS version it was released with. Again, the "needs version" label should be applied because delays can happen in actual review and merge
  • similar for Prebid Server bid adapters except the metadata fields should be "pbs_go_version" and "pbs_java_version". So yes, many adapters could have 3 versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants