nodejs/package-maintenance

[best practices] managing LTS & release lines for userland modules

Open

#172 opened on Mar 8, 2019

View on GitHub
 (12 comments) (1 reaction) (0 assignees) (147 forks)github user discovery
articlehelp wantedquestion

Repository metrics

Stars
 (419 stars)
PR merge metrics
 (PR metrics pending)

Description

I'm starting a discussion in Mocha around how we can best support multiple "LTS" release lines.

I'm familiar with what Node.js itself does (though I haven't ever cut a Node.js release myself; it seems essentially like trunk-based development). But I don't have an understanding of all the gotchas around something like this.

It does seem that, without proper tooling, maintainers will be in for a lot of pain in addition to the extra overhead that the strategy initially incurs.

I also don't know how other teams/projects that want to do long-lived release lines do it, and would love to hear from them!

How can we, as the package maintenance team, help projects that want to take this on? What works and what doesn't?

Contributor guide

Research direction
Research how other open source projects manage LTS release lines, particularly focusing on tooling and maintenance overhead. Look at Node.js's own LTS process and survey other userland modules.
Tech stack
nodejs
Domain
release
Issue type
Research
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
2
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
None
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40