NLB-6564: Updated NIGNXaaS dataplane change log with version information

[xynicole]

Proposed changes

Added an additional changelog page for version information, as this page would become very lengthy.

Closes #ISSUE

Checklist

Before merging a pull request, run through this checklist and mark each as complete.

• I have read the contributing guidelines
• I have signed the F5 Contributor License Agreement (CLA)
• I have rebased my branch onto main
• I have ensured my PR is targeting the main branch and pulling from my branch from my own fork
• I have ensured that the commit messages adhere to Conventional Commits
• I have ensured that documentation content adheres to the style guide
• If the change involves potentially sensitive changes¹, I have assessed the possible impact
• If applicable, I have added tests that prove my fix is effective or that my feature works
• I have ensured that existing tests pass after adding my changes
• If applicable, I have updated README.md and CHANGELOG.md

Footnotes

1. Potentially sensitive changes include anything involving code, personally identify information (PII), live URLs or significant amounts of new or revised documentation. Please refer to our style guide for guidance about placeholder content. ↩

[github-actions]

✅ Deploy Preview will be available once build job completes!

Name	Link
😎 Deploy Preview	https://frontdoor-test-docs.nginx.com/previews/docs/632/

---

[ryepup]

this content looks fine to me, there's some debate in slack on whether to put in the normal changelog or have a different page. I'm fine either way.

In the very, very, very long run, this might be something to automate; our CI pipelines that deploy these dataplane images could publish the version data somewhere and a bot opens a PR.

[amudukutore]

I don't mind that these entries are sorted alphabetically (it's a predictable ordering). I do feel we can organize this data a bit better - perhaps something along these lines:

Category	Name	Version	Description
NGINX	nginx-plus	1.27.2 (nginx-plus-r33-p2)	NGINX Plus, provided by Nginx, Inc.
	nginx-agent	1.19.15-1795423089	NGINX Agent - Management for NGINXaaS.
Operating System	Ubuntu	22.04.5	Jammy Jellyfish, provided by Canonical Ltd.
NGINX Modules	module-1	1.2.3	Module 1 description
	module-2	1.2.3	Module 2 description
	module-3	1.2.3	Module 3 description

Here's an alternative approach which doesn't add an extra column and retains width on the existing columns (I like this one better):

Name	Version	Description
NGINX
nginx-plus	1.27.2 (nginx-plus-r33-p2)	NGINX Plus, provided by Nginx, Inc.
nginx-agent	1.19.15-1795423089	NGINX Agent - Management for NGINXaaS.
Operating System
Ubuntu	22.04.5	Jammy Jellyfish, provided by Canonical Ltd.
NGINX Modules
module-1	1.2.3	Module 1 description
module-2	1.2.3	Module 2 description
module-3	1.2.3	Module 3 description
NGINX App Protect
nginx-plus-module-appprotect	5.264.0	NGINX Plus app protect dynamic module version 5.264.0
app-protect-module-plus	5.264.0	App-Protect package for Nginx Plus, includes all of the default files and examples. NGINX App Protect provides web application firewall (WAF) security protection for your web applications, including OWASP Top 10 attacks.
app-protect-plugin	6.9.0	NGINX App Protect plugin

[JTorreG]

I think the layout proposed by @amudukutore is better but keep in mind that currently we need to work with the table limitations imposed by Hugo (so we can't join cells)

I know the engineering team is currently looking on improving the table options, but this is still in the kitchen.

[amudukutore]

My proposal above was built using HTML tables to get the desired formatting (since github Markdown tables are fairly limited).
@JTorreG - do the current limitations imposed by Hugo impact our usage of HTML tables?

[JTorreG]

We should not use raw HTML for anything, inc. tables.

[amudukutore]

It would be good to understand why we can't use HTML tables. Also, what options do we have for tables today? Are we stuck with github-flavored Markdown tables (and their limitations) or can we do better?