jaegertracing / jaegertracing/documentation

Version 1 EOL followup

Open
#1,055 0 comments 0 reactions 1 assignee View on GitHub

@chalin is already working on this.

Since Jan 13, 2026.

Dominant language
TypeScript
Stars
84
Forks
192
Avg merge
12h 25m
Merged PRs (30d)
4

Description

### Requirement

From https://github.com/jaegertracing/documentation/issues/1054#issuecomment-3735564712:

> [@yurishkuro](https://github.com/yurishkuro), after giving this more thought, I'd like to argue that the most appropriate action for end users is to:
>
> * Keep 1.76 pages indefinitely
> * Redirect 1.x pages to the corresponding 1.76 page, assuming it exists, or to the 1.76 landing page otherwise.
>
> Why?
>
> 1. **URLs are like public APIs.** There are lots of URLs to 1.x pages out there (blogs, runbooks, tickets, vendor docs, PDFs, bookmarks including OTel.io blog posts). Simply deleting them is a serious breaking change that just leaves clients **confused** and unaware of any suggested migration path.
> 2. By keeping 1.76 pages, **we can clearly mark v1 as EOL and funnel users to v2.** That is, add a banner to 1.76 pages + links to migration + 2.x equivalents so that users are informed, not surprised.
> 3. **Redirecting 1.x → latest 2.x silently changes semantics.** You propose redirecting to 2.x pages, but users following an old link expect 1.x behavior. Landing on 2.x can give wrong flags, configs, or deployment instructions — a correctness bug, not just UX.
> 4. **Keeping 1.76 pages has a _very low_ support burden.**

### Tasks

- [x] Redirect 1.x pages to corresponding 1.76 page if it exists, otherwise to the 1.76 landing page - #1056
- [ ] ...

As specified by @yurishkuro in #1054:

- [ ] Add banner to 1.76 pages. See Download page example below.
- [ ] Drop "latest) from "1.76 (latest)" since it's misleading

Reference, examples:

> on Download page we have a warning
>
> Image

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.