Every product update, fix and new release.

They are editorial categories — a way to colour and tag each entry so you can scan the list and find the kind of change you care about without reading every line. They are not contractual terms and they are not billing tiers, so it is worth holding them loosely. Roughly: “New Feature” marks a capability that did not exist before; “Improvement” marks something that already existed getting better, faster, clearer or broader; “Bug Fix” marks a defect being corrected so the product behaves the way it was supposed to; and “Security” flags a change that is security-relevant — a hardening, a patched weakness, an update that matters for the safety of your data rather than for what you can do with the product. That last label is the one to read carefully, because it is the one people filter on. A Security badge is a signal that the entry touches security, which is exactly what you want when you are triaging. But a badge on a marketing page is not a security advisory, does not promise a severity rating, and does not guarantee that every security-relevant change is represented here. For the authoritative view of security changes — what was addressed, in which version, and whether any action is required of you — use the in-product release notes and the Security Center at /security. Where an entry could sit under two labels, we pick the one that best describes the headline change; the detail in the release note itself is more precise than the badge.

There is usually a subscribe option on the page for keeping up with releases, and for security specifically the Security Center at /security is the place to look — but read the honest caveat first. The subscribe box shown on this page is illustrative: it is a placeholder that demonstrates where a signup would sit, not a live form wired to a mailing list, so typing your address into the version on this marketing page is not a reliable way to get onto anything. To actually receive release announcements and security advisories, use the real signup or contact route — the in-product notifications and the subscription controls inside your account, or the contact details in /documentation and the Security Center — rather than the box drawn here. The distinction matters most for security. If you need to be told when a security-relevant change ships, or you want to be on whatever advisory list exists, set that up through the proper channel and confirm you are actually on it, because a placeholder that looks like it worked is worse than one that plainly does not. For anything touching security notifications, treat /security as the front door: it points to how advisories are communicated and how to reach the people who handle them. And if you are unsure whether you are subscribed to the right thing, ask through support rather than assuming the form on this page did the job.

The tags you see on the entries — v2.4.5 and the like — are semantic-looking version numbers, three numbers separated by dots, in the familiar major-minor-patch shape. The intuition most people already have is roughly right: a change in the first number tends to signal something large, the middle number tends to move with new functionality, and the last number tends to move with small fixes and patches. That is a useful way to read them at a glance, and it is the reason the format is used. What this page should not do is turn that intuition into a promise. We are not going to claim a formal SemVer contract here — a strict guarantee that every increment obeys the specification to the letter, that nothing breaking ever ships outside a major bump, or that the numbering carries a compatibility commitment you can hold us to from a marketing badge. Version numbering, and just as importantly the deprecation policy that sits alongside it — how long an old behaviour is supported, how changes are signalled before they land, what notice you get — is documented properly in /documentation, and that is the version of the answer to rely on. So: read the tags as a helpful signal of the size of a change, use them to orient yourself, and when you need certainty about compatibility, upgrade impact or how long something you depend on will keep working, go to the docs for the actual policy rather than inferring it from the shape of a number on this page.

In the product and in the docs, not on this page. This changelog page is a curated, illustrative window — a handful of entries chosen to show the kinds of thing Vertex ships and how we write them up. The real material sits in two places. The detailed release notes live in /documentation, where each release is written up properly: what changed, in which version, what you may need to do, and any deprecation or migration notes attached to it. And the full archive — the complete, dated history going back rather than the recent highlights shown here — is available in-product, inside your account, where you can see it against the environment you actually run and filter it to what is relevant to you. That in-product archive is the authoritative record; treat it, and the docs, as the source of truth whenever a date, a version or an exact wording matters. If you cannot find a specific release, need an older entry that is not surfaced, or want something exported for a change-management or audit process, route that to support — they can point you to the right entry or pull the archive detail you need. The short version: highlights here, the readable write-ups in /documentation, the complete dated archive in-product, and anything you cannot locate through support.