Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release ICU4X 1.3 #4065

Closed
18 tasks done
Manishearth opened this issue Sep 21, 2023 · 8 comments
Closed
18 tasks done

Release ICU4X 1.3 #4065

Manishearth opened this issue Sep 21, 2023 · 8 comments
Assignees

Comments

@Manishearth
Copy link
Member

Manishearth commented Sep 21, 2023

Pre-release checklist

This is a checklist of things that should be done in the weeks leading to the release.

  • Verify that the milestone and checklist are complete
  • Verify with component owners that they're ready for release
  • Take a bird-eye view at:
    • READMEs
    • Documentation
    • Coverage
    • Performance / Memory / Size benchmarks
    • Cargo.toml files
      • All dependencies from the workspace should use workspace = true rather than their version number or path
      • Cargo.toml files need to specify versions for each non-workspace entry in dependencies, or use workspace = true.
      • Ensure that any new packages have version number 0.0.0, this will making bumping during the release easier.
      • Ensure that the Cargo.toml file includes a set of fields consistent with other ICU4X packages.
        • These should mostly use workspace inheritance
  • Run cargo +nightly fmt -- --config=format_code_in_doc_comments=true --config=doc_comment_code_block_width=80 to prettify our docs
  • Run cargo update for each Cargo.lock file to update our CI to freshest dependencies
  • Go through ffi/diplomat/tests/missing_apis.txt and verify that it is empty. If it is not, component owners should either add FFI APIs, add rust_link annotations, or allowlist the relevant APIs as having been punted to the future
  • Verify that ffi/diplomat depends on a released (not Git) version of Diplomat. Get it published (ask manishearth or sffc) otherwise.
  • Start work on a changelog (see below)
  • Prepare a PR to update tutorials using the upcoming release. The PR should pass cargo make test-tutorials-local, but can fail cargo make test-tutorials-cratesio prior to release

Release steps

Once the release checklist is complete, the assigned release driver will perform the following steps, in order:

  • Go through the prerelease checklist again, ensuring that no problems were reintroduced in the PRs that landed since the opening of the checklist. (Things like doc prettification will likely need to be rerun!)
  • Release utils (see section below). Get the version bumps reviewed and checked in before releasing. (1.3 utils release list #4066)
  • Update ICU4X package versions as needed. Most of this can be done by updating workspace.package in the root Cargo.toml and the workspace.dependencies entries there. Some icu_* crates do not follow the ICU4X versioning scheme like icu_codepointtrie_builder or experimental crates.
  • Temporarily add icu_testdata back to the workspace
    • To build, run cargo make testdata-legacy-gen to generate the gitignored data
  • Get this reviewed and checked in before continuing
  • Publish each icu_* crate
    • Use cargo workspaces publish --from-git to automatically publish the crates in the correct order if you would like
    • Add icu4x-release group as owners to each new component you're publishing
      • cargo owner -a github:unicode-org:icu4x-release
  • Merge the tutorials PR. cargo make test-tuturials-cratesio should now pass
    • If there are any errors, please fix them before advertising the release
  • Tag the Release
  • Land the changelog (see below)
  • Announce the release to public
@Manishearth Manishearth mentioned this issue Sep 21, 2023
13 tasks
@Manishearth Manishearth changed the title Release icu4x 1.3 Release ICU4X 1.3 Sep 21, 2023
@sffc
Copy link
Member

sffc commented Sep 21, 2023

The task "birds-eye view at benchmarks" caused me to file #4067

@sffc
Copy link
Member

sffc commented Sep 23, 2023

I get the following errors when trying to publish components/locid:

$ cargo publish
    Updating crates.io index
warning: license-file `../../LICENSE` appears to be a path outside of the package, but there is already a file named `LICENSE` in the root of the package. The archived crate will contain the copy in the root of the package. Update the license-file to point to the path relative to the root of the package to remove this warning.
   Packaging icu_locid v1.3.0 (/home/sffc/projects/icu4x/components/locid)
    Updating crates.io index
error: failed to prepare local package for uploading

Caused by:
  failed to select a version for the requirement `icu = "~1.3.0"`
  candidate versions found which didn't match: 1.2.0, 1.1.0, 1.0.0, ...
  location searched: crates.io index
  required by package `icu_locid v1.3.0 (/home/sffc/projects/icu4x/components/locid)`
  perhaps a crate was updated and forgotten to be re-vendored?

I can solve the warning by changing the license-file back to a per-component one but I don't know if that's a good or bad change. I might put up a PR for this anyway and let someone approve or reject it.

The second one is because { workspace = true } seems to imply the version number rather than path when publishing. The way to work around this problem is to just always use paths. I am putting up a PR changing all the workspace = true to path imports in dev dependencies.

@sffc
Copy link
Member

sffc commented Sep 25, 2023

I released the first version of many new crates (the data crates); I went through and ran cargo owner -a github:unicode-org:icu4x-release for them

@robertbastian
Copy link
Member

These crates haven't been released:

  • icu4x_ecma402
  • icu_harfbuzz

@sffc sffc added this to the 1.3 Blocking ⟨P1⟩ milestone Oct 5, 2023
@sffc
Copy link
Member

sffc commented Oct 5, 2023

@sffc
Copy link
Member

sffc commented Oct 10, 2023

This is all done except I haven't yet submitted to This Week In Rust. I don't know how often we should consider submitting to that; is it okay to do it for every release, or should we rate-limit to once a year? @Manishearth

@Manishearth
Copy link
Member Author

Once a release is fine

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants