1 of 36

endoflife.date recommendations

How to document support lifecycles effectively.

2 of 36

whoami

3 of 36

4 of 36

angular

laravel

5 of 36

The Gold Standard

6 of 36

php

7 of 36

kubernetes

endoflife.date/k8s

8 of 36

Understanding

Expectations

9 of 36

Questions your release page is asked

Updates

Support

Compatibility

Lifecycle

Release Distinction

Policy

Am I running a supported release? What does support mean?

What changes were made in release X. Will something break?

Is there a new releases available? When is the next one due?

How long will release X get bug fixes or security fixes?

Should I be running a LTS release? What’s the difference?

How are new releases versioned?

10 of 36

Recommendations

11 of 36

Empathy

Be Helpful.

12 of 36

In One Place

Stick to one page, one website.

13 of 36

Publishing

GOOD

BAD

wiki.ubuntu.com/ReleaseCadence

ubuntu.com/about/release-cycle

wiki.ubuntu.com/Releases

​

example.com/docs/v3.4/eol (?)

devguide.python.org

example.com/docs/eol

example.com/release-policy

angular.io/guide/releases

php.net/supported-versions.php

14 of 36

Document the lifecycle

Tell what’s supported and for how long

15 of 36

Release�Cadence

How often are you making new releases?

16 of 36

Release Cadence

GOOD

BAD

Saying nothing.

  • Ubuntu
  • Every month
  • Every Christmas (Ruby)
  • Every 29th February
  • Maybe once every 2 weeks, but not guaranteed.
  • Whenever needed.
  • No release cadence.

17 of 36

What does

Support mean?

18 of 36

Different Meanings

Conditions Applied*

  • Priority security fixes.
  • Critical bugfixes.
  • Issues will be looked at
  • Community Forum for support.
  • Only packages in the “main” repository.
  • Only if you are a paying customer.
  • Free for 3 machines.
  • Only packages covered by our upstream LTS.
  • As long as you’re running a support Python version.

19 of 36

What is supported?

Provide a list of “supported releases”.

20 of 36

elasticsearch

21 of 36

Dates

Be accurate, and exact.

22 of 36

How to document dates correctly

Absolute Dates

No Ambigous Dates

Complete Dates

“2022 December” might mean upgrading on new year or not.

Don’t make your users do the math every time.

07-07-2021 is bad.

RFC3339 FTW!

23 of 36

Calendar Images

24 of 36

Good Release Calendar Images

  • Clearly labelled X-axis (Years, Quarters)
  • Well sorted releases.
  • Mark the current date
  • (Interactive) Show information on hover.
  • Keep it updated!
  • Accessible

25 of 36

26 of 36

ubuntu

27 of 36

Essential Information

What all to document

28 of 36

What all to list for every release cycle

Changelog

Dates

Download/Upgrade Links

Migration Guide

Unsupported Releases

Latest

How do I get this release?

Helpful for complicated upgrades.

Don’t list these alongside supported ones.

A link to the changelog for the latest release, not just the first one.

What’s the latest release in this cycle (and is it supported)?

Release, Latest Release Date, LTS Date, Support, EOL

29 of 36

Showcase

30 of 36

Node.js

  • Changelog
  • Latest Release
  • Dates
  • Download
  • Migration
  • Unsupported Releases
  • Today’s Date

BONUS

  • Future releases
  • Calendar

31 of 36

kubernetes

  • Changelog
  • Latest Release
  • Dates
  • Download
  • Migration
  • Unsupported Releases

32 of 36

Python

  • Changelog
  • Latest Release
  • Dates
  • Download
  • Migration
  • Unsupported Releases

33 of 36

Azure Kubernetes Service

  • Changelog
  • Latest Release
  • Dates
  • Release Notes
  • Unsupported Releases

34 of 36

Amazon EKS

  • Changelog
  • Latest Release
  • Dates
  • Release Notes
  • Unsupported Releases

35 of 36

haproxy

  • Changelog
  • Latest Release
  • Dates
  • Download
  • Migration
  • Unsupported Releases

36 of 36

Be Helpful

🔗endoflife.date/recommendations

Credits & Slides: captnemo.in/talks