Commit graph

10 commits

Author SHA1 Message Date
Jan Martin
deec4c16fd docs: call out cleanup steps in devtools release process (#62769)
PR Close #62769
2025-07-24 09:16:12 +00:00
Doug Parker
e63cd1f405 docs: update Angular DevTools release docs (#62352)
This makes few edits based on feedback and observations from a previous release:
1.  Moves `git pull` command before initial `git log` to make sure we're up to date before checking if a release is necessary.
2.  Updates both `git log` commands to limit to `fix`, `feat`, and `perf` changes. This ignores more than just `refactor`, such as `build`, `ci`, etc. and should be more meaningful to end users.
    *   I considered doing something with `Revert` commits, but opted not to. Instead, it will treat this just like their original commit. This does mean we might send a slightly more complicated changelog than it needs to be, but it's not worth making these commands even weirder.
3.  Removes install step prior to bumping the version numbers, as its just not needed and we have to reinstall later anyways.
4.  Switches PR target from `patch` to `minor`. We only need to merge this to the `main` branch, and it's not worth the effort to keep the `patch` branch in sync.
5.  Switches source code zip command to `git archive`. This is more portable than `zip *`, which depends on the shell configuration to determine what is included in `*` (mainly whether or not that includes dotfiles such as `.nvmrc` and `.bazelrc`).

PR Close #62352
2025-06-30 07:36:19 +00:00
Doug Parker
38f8705aab docs: adds --jobs 4 to Firefox release flags (#62015)
This seems to be helpful for Mozilla reviewers to reproduce the build without encountering Bazel errors like:

```
Server terminated abruptly (error code: 14, error message: 'Socket closed', log file: '/home/parallels/.cache/bazel/_bazel_parallels/ae710c6507eb251f9511ac4228641059/server/jvm.out')
```

`--local_ram_resources` is also useful, but I'm not sure what to set it to by default or how necessary it is, so let's just start with `--jobs 4` for now. The 4 is arbitrary as I don't have insight into how many jobs are actually appropriate, but we can go with this for now and tweak the number later if it still causes issues.

PR Close #62015
2025-06-12 13:48:39 +02:00
Doug Parker
c45afbc2a8 docs: streamline DevTools release docs (#61883)
This makes a few changes to try to smooth over the process:
1. Updates changelog commands to filter out `refactor` commits.
2. Tweaks the changelog command to generate a markdown list for easy copy-pasting.
3. Links directly to the store pages to cut down on clicks.
4. Moves the source code section a bove the reviewer note and changelog, to match the ordering of the Firefox Add Ons form.

PR Close #61883
2025-06-05 09:56:57 +02:00
Doug Parker
35b944dbec refactor(devtools): remove release process overview and add step to check for release (#60892)
The release process overview is out of date and does not accurately reflect section headers. It's not worth the maintenance effort of keeping it in sync with the rest of the doc.

Added a step 0 to check if there's actually anything to release, reusing the command from later in the doc.

Also makes a few random small corrections to reflect the new release process.

PR Close #60892
2025-05-15 09:42:51 -07:00
Doug Parker
b2c8fb3c6b refactor(devtools): update release process to commit before publishing (#60646)
This moves the commit step to the start of the process and releases after merging it. This has two key benefits:
1. The commit history now reflects the actual release (ex. any DevTools commits before the release commit are actually included in that release). Previously the changes in a release were dictated by the release PR branch, which is an ephemeral target. Other PRs may be merged to `main` before the release PR, and those changes would not be included in that DevTools release.
2. We can now compute a changelog based on this more accurate history.

The downside to this change is that release PRs are now blocking releases in a way they weren't before (which is likely desirable in the grand scheme of things), meaning we need to be more diligent about merging them in a timely manner.

I added a short script for listing DevTools commits since the last release, taking advantage of the more accurate commit history. This should make changelog generation a lot easier, even if there's still a manual process of rewriting the commit message into a line item in release notes.

Also made a few minor cleanup changes such as escaping the markdown in the suggested reviewer note so it can be more easily copy-pasted from the rendered format of this doc.

PR Close #60646
2025-04-15 09:19:39 -04:00
Doug Parker
be32d63652 docs: update zip command and link to recent DevTools commits (#59792)
`-x dist/` never worked for reasons I don't really understand. Historically I've just deleted `dist/` before zipping. I tried a few different approaches, but all of them lead to some form of "Name not matched" error in `zip` of the `dist/` directory. Instead I just opted to delete `dist/` as part of the zipping command.

The link to recent DevTools commits seems good enough to manually write a changelog. All relevant commits should be using `refactor(devtools)`, so the string "devtools" should definitely be in there.

PR Close #59792
2025-02-14 19:31:59 +00:00
Sam Knutson
042ee75d1b docs: fix spelling of "set up" (#58362)
Fix spelling of the word "set up" in docs. "Setup" (one word) is a noun
whereas "set up" (two words) is a verb.

Fixes #58361

PR Close #58362
2025-02-03 13:50:49 -08:00
Doug Parker
bd953c7847 docs(devtools): remove duplicate text at end of release.md doc (#57222)
Somehow the last few lines got duplicated at the end of this doc. Definitely not needed.

PR Close #57222
2024-08-02 16:52:41 +00:00
Doug Parker
d2d275a275 docs(devtools): update README to be more clear for extension reviewers (#55406)
Mozilla requires add-ons to have reproducible builds and this is managed directly by human reviewers and need to understand how to build Angular DevTools correctly. This commit defines a reproducible way of building Angular DevTools which is useful for reviewers and contributers.

The actual changes I made include:
1. Moving local development content into `devtools/README` (deleting `devtools/DEVELOPING.md`) and explicitly stating the Node version as well as global Yarn install to be clear about the correct way to build the extension. This should make it easier for reviewers to understand and reproduce builds.
2. Moving release instructions to a separate doc to reduce noise as well as making some minor clean ups there.

I briefly considered pointing reviewers at a new `devtools/docs/reviewers.md` doc, but decided against it because I want these instructions to be maintained in a single location where contributors and reviewers use the same content. This way any changes don't miss one of these sets of users. If reviewers have trouble with this format (dev builds isn't useful to reviewers and some content is repeated from other docs for contributors) then we can consider splitting out to a separate `reviewers.md` file. But until then, I'd like to try sharing this content and see how it works out in practice.

PR Close #55406
2024-04-23 13:02:49 -07:00