meta: LTS strategy #8
Comments
|
would love input or suggestions from anyone in @nodejs/package-maintenance or @nodejs/release |
|
I'll create some issues there for cross-reference |
|
There will still be only one single |
Several projects I've seen are simply moving to ES6 and requiring Babel to support IE. |
|
Note also that this merge style will need each PR to be much more focused. |
|
Conventional process sounds solid. Development for contributors seems largely the same except if bug only against specific release, will have to document process, I'm sure that's part of the plan. More tooling (i.e. cherry-pick latest changesets for release branch) sounds really useful, I'm wondering if we can use it for changelog. Not crucial at this point. |
|
IMO the changelogs must be written manually. It’d be nice to pre-fill it with the list of commits/PRs though, so we at least have a place to start. |
|
The drawback of dropping IE support is that it will become more difficult to cherry-pick fixes, since ostensibly we will want to modernize our codebase. We could also just not worry about backporting anything and only apply critical fixes. It really kind of depends on what the foundation requires, but we should shoot for minimizing what we must backport to an old release line. Thankfully Mocha isn’t run in production, so the bar for “critical fix” is pretty high. |
|
I like to support LTS releases while I don't have much experience for LTS release. |
|
We can't really settle on an LTS strategy until we've discussed this with the Foundation. However, we can propose something. I think we can also leverage GitHub Actions to help. |
|
ref: nodejs/Release#451 |
|
In here sounds like we are in relative agreement on the process (i.e. trunk-based). Is next step to formalise? |
|
Thinking about this trunk-based development: But for LTS this is not a good way to develop. Let's say we drop IE11 support for v7. After short time our |
|
I strongly doubt that Node has one |
|
I had a look at Node's GH repository. If I got it right, they don't use trunk-based development. Currently they have three "master" branches which are maintained independently by separate PR's. Cherry-picking seems to be used just for the newest release v12. They have following branches:
|
|
I didn't fully understand how node core team handle multiple branches. Why do you think that |
|
Probably they do both:
You can read commit messages like:
Whatever ... they don't do trunk-based development. The Guys, we should make decisions, this is a core task of a team. We can't always wait for others taking decision for us. At this moment there are no others. |
|
@juergba is right, it's not trunk-based development. Also, we aren't really in a rush to do this. We haven't even gotten to the point where we sit down with the CPC and determine what exactly they expect from us. That doesn't mean we can't go ahead and implement something, but I just wanted to be clear about the urgency (or lack thereof). |
|
Slightly different note. My understanding is our |
To support "LTS"--or long-running releases--we will need to make some development workflow changes.
In terms of a branching strategy, I'm thinking the most reasonable approach would be trunk-based development, which I had experimented with before without knowing what it was called. Node.js uses something very similar to this.
In a nutshell:
master(except in the case that the bug cannot be reproduced inmaster; it then must happen on release branches)mastermasterinto the release branchmastermasterand merged via a PR. note that this includes bug fixes, "chores"--pretty much anything.master, if it makes sense.master.In addition to whatever we're going to get from users reporting bugs against multiple release lines, this is the overhead we're looking at for LTS releases. There are some tools available which we can either use outright or adapt for our uses (from the Node.js project), but we may need a purpose-built solution. For example, it'd maybe make sense to automatically attempt cherry-picking of new changesets in
masterinto the active release branches.(AFAIK, cherry-picking is used because otherwise each changeset in
masterwould create an extra merge commit when pulled into an active release branch.)A noted headache is cross-referencing changesets with their original PRs (due to the loss of context created when a changeset is cherry-picked instead of merged). It becomes critical to link to the PR number somewhere in the commit message. Of course, you can't add the PR to the commit message when you create a changeset, so the commit message must be amended at time-of-merge. Node.js also has tooling (and a convention) around this.
Another unconventional way to tackle this is to literally snapshot the codebase for each release line and stuff it in some subdirectory. I'm pretty sure I didn't just dream this up. Anyway, I don't think the tooling's there to support this sort of thing, though at its core, it sounds similar to a monorepo. The major challenge would be to coordinate patch application across multiple directories, assuming something like Lerna could manage the rest of it. While the above branching solution is non-trivial, I still don't see a clear advantage; both will require tooling.
cc @mochajs/core
The text was updated successfully, but these errors were encountered: