Release 0.15

[BigLep]

Items to do upon creating the release issue

• Fill in the Meta section
• Assign the issue to the release owner and reviewer.
• Name the issue "Release v0.15.0"
• Set the proper values for X.Y.Z
• Pin the issue

Meta

• Release owner: @ajnavarro
• Release reviewer: @Jorropo
• Expected RC date: 2022-08-18
• Expected final release date: 2022-08-25 2022-08-29
• Accompanying PR for improving the release process: Update RELEASE_ISSUE_TEMPLATE.md #9213

See the Kubo release process for more info.

Initial planning

Themes

1. Clean up cruft
2. Communicating outwards from IPFS Thing
3. Bitswap

• Priority: knowledge transfer
• Finish separation
• Improve server
• Leverage test-plans
• Final validate by deploying to a Cluster

5. Reframe followup
6. Gateway improvement followups?

Items we're explicitly not doing

1. Kubo RPC cleanup: Point users at canonical kubo/client/rpc library #9124?
2. Repo consolidation
3. Enabling libp2p resource manager

Kubo 0.15.0 Release

We're happy to announce Kubo 0.15.0, bla bla...

As usual, this release includes important fixes, some of which may be critical for security. Unless the fix addresses a bug being exploited in the wild, the fix will not be called out in the release notes. Please make sure to update ASAP. See our release process for details.

🗺 What's left for release

<List of items with PRs and/or Issues to be considered for this release>

🔦 Highlights

This is a release mainly with bugfixing and library updates.
We are improving release speed and cadence trying to have a new release every 5 weeks.

#️⃣ Blake support

You can now use blake3 as a valid hash function: ipfs block put --mhtype=blake3.
It uses a 32 bytes default size.
To use other hash length set mhlen: ipfs block put --mhtype=blake3 --mhlen=64

💉 Fx Options plugin

This adds a plugin interface that lets the plugin modify the fx options that are passed to fx when the app is initialized.
This means plugins can inject their own implementations of IPFS interfaces.
This enables granular customization of go-ipfs behavior by plugins, such as:

• Bitswap with custom filters (e.g. for CID blocking)
• Custom interface implementations such as Pinner or DAGService
• Dynamic configuration of libp2p ...

Here's an example plugin that overrides the default Pinner with a custom one:

func (p *PinnerPlugin) Options(opts []fx.Option) ([]fx.Option, error) {
	ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
	defer cancel()
	cfg, err := config.LoadDefaultConfig(context.Background())
	if err != nil {
		return nil, fmt.Errorf("loading AWS config: %w", err)
	}
	logger, err := zap.NewProduction()
	if err != nil {
		return nil, fmt.Errorf("constructing logger: %w", err)
	}
	smClient := secretsmanager.NewFromConfig(cfg)
	pinsDB, err := db.NewPinsDB(ctx, logger.Sugar(), smClient)
	if err != nil {
		return nil, fmt.Errorf("constructing PinsDB: %w", err)
	}
	pinner := &pinner.Pinner{PinsDB: pinsDB}
	return append(opts, fx.Replace(fx.Annotate(pinner, fx.As(new(pin.Pinner))))), nil
}

Extra plugin info here.

✅ Release Checklist

For each RC published in each stage:

• version string in version.go has been updated (in the release-v0.15.0 branch).
• new commits should be added to the release-v0.15.0 branch from master using git cherry-pick -x ...
• tag commit with v0.15.0-rcN
• add artifacts to https://dist.ipfs.tech
  1. Make a PR against ipfs/distributions with local changes produced by add-version (see usage)
  2. Wait for PR to build artifacts and generate diff
  3. Inspect results, merge if CI is green and the diff looks ok
  4. Wait for master branch to build and update DNSLink at https://dist.ipfs.tech
• cut a pre-release on github and reuse signed artifacts from https://dist.ipfs.tech/kubo (upload the result of the ipfs/distributions build in the previous step).
• Announce the RC:
  • Create a new post on Discuss
    • This will automatically post to IPFS Discord #ipfs-chatter
    • Examples from the past: 0.14.0
  • Pin the topic. You need admin privileges for that.
  • To the early testers listed in docs/EARLY_TESTERS.md. Do this by copy/pasting their GitHub usernames and checkboxes as a comment so they get a GitHub notification. (example)

Checklist:

• Stage 0 - Automated Testing
  • Upgrade to the latest patch release of Go that CircleCI has published
    • See the list here: https://hub.docker.com/r/cimg/go/tags
    • ipfs/distributions: bump this version
    • ipfs/kubo: example PR
  • Fork a new branch (release-v0.15.0) from master and make any further release related changes to this branch. If any "non-trivial" changes (see the footnotes of docs/releases.md for a definition) get added to the release, uncheck all the checkboxes and return to this stage.
    • Follow the RC release process to cut the first RC.
    • Bump the version in version.go in the master branch to vX.(Y+1).0-dev.
  • Automated Testing (already tested in CI) - Ensure that all tests are passing, this includes:
    • unit, sharness, cross-build, etc (make test)
    • lint (make test_go_lint)
    • interop
    • go-ipfs-api
    • go-ipfs-http-client
    • WebUI
• Stage 1 - Internal Testing
  • CHANGELOG.md has been updated (chore: Add v0.15.0 CHANGELOG notes. #9220)
    • use ./bin/mkreleaselog to generate a nice starter list
  • Infrastructure Testing:
    • Deploy new version to a subset of Gateways (https://github.com/protocol/bifrost-infra/issues/2046)
    • Deploy new version to a subset of Bootstrappers (https://github.com/protocol/bifrost-infra/issues/2055)
    • Deploy new version to a subset of Cluster nodes (https://github.com/protocol/bifrost-infra/issues/2055)
    • Collect metrics every day. Work with the Infrastructure team to learn of any hiccup
  • IPFS Application Testing - Run the tests of the following applications:
    • IPFS Desktop
      • Ensure the RC is published to the NPM package (happens automatically, just wait for CI)
      • Upgrade to the RC in ipfs-desktop and push to a branch (example), and open a draft PR to track through the final release (example) feat: Kubo 0.15.0 ipfs-desktop#2240
      • Ensure CI tests pass, repeat for new RCs
    • IPFS Companion - @lidel
• Stage 2 - Community Prod Testing
  • Documentation
    • Ensure that CHANGELOG.md is up to date (chore: Add v0.15.0 CHANGELOG notes. #9220)
    • Ensure that README.md is up to date
    • Update docs by merging the auto-created PR in https://github.com/ipfs/ipfs-docs/pulls (they are auto-created every 12 hours)
  • Invite the wider community through (link to the release issue):
    • discuss.ipfs.io
    • Matrix
• Stage 3 - Release
  • Final preparation
    • Verify that version string in version.go has been updated.
    • Open a PR merging release-v0.15.0 into the release branch.
      • This should be reviewed by the person who most recently released a version of go-ipfs.
      • Use a merge commit (no rebase, no squash)
    • Prepare the command to use for tagging the merge commit (on the release branch) with v0.15.0.
      • Use git tag -s to ensure the tag is signed
    • Have the tagging command reviewed by the person who most recently released a version of go-ipfs
      • This is a dangerous operation, as it is difficult to reverse due to Go modules and automated Docker image publishing
    • Push the tag
      • Use git push origin <tag>
      • DO NOT USE git push --tags, as it will push ALL of your local tags
      • This should initiate a Docker build in GitHub Actions that publishes a v0.15.0 tagged Docker image to DockerHub
    • Release published
      • to dist.ipfs.tech
      • to npm-go-ipfs (done by CI at ipfs/npm-go-ipfs, but ok to dispatch this job manually)
      • to chocolatey (done by CI at ipfs/choco-go-ipfs, but ok to dispatch this job manually)
        • Manually run the release workflow
        • Wait for Chocolatey to approve the release (usually takes a few hours)
      • to snap (done CI at snap/snapcraft.yaml)
      • to github
        • After publishing the GitHub release, run the workflow to attach the release assets: https://github.com/ipfs/go-ipfs/actions/workflows/sync-release-assets.yml
      • to arch (flag it out of date)
    • Cut a new ipfs-desktop release
  • Get a blog post created
    • Submit a request using this form.
    • Notify marketing in #shared-pl-marketing-requests about the blog entry request (since the form gets spam).
    • Don't mark this as done until the blog entry is live.
  • Broadcasting (link to blog post)
    • Twitter (request in Filecoin Slack channel #shared-pl-marketing-requests)
    • Reddit
    • discuss.ipfs.io
      • A bot auto-posts this to Discord and Matrix
• Post-Release
  • Merge the release branch back into master, ignoring the changes to version.go (keep the -dev version from master).
  • Create an issue using this release issue template for the next release.
  • Make sure any last-minute changelog updates from the blog post make it back into the CHANGELOG.
  • Mark PR draft created for IPFS Desktop as ready for review.

⁉️ Do you have questions?

The best place to ask your questions about IPFS, how it works and what you can do with it is at discuss.ipfs.io. We are also available at the #ipfs channel on Freenode, which is also accessible through our Matrix bridge.

Release improvements for next time

< Add any release improvements that were observed this cycle here so they can get incorporated into future releases. >

Items for a separate comment

< Do these as a separate comment to avoid the main issue from getting too large and checkbox updates taking too long. >

Changelog

Changelog

https://github.com/ipfs/kubo/blob/master/docs/changelogs/v0.15.md

[BigLep]

2022-07-26 sync

Agenda

1. High level priorities

(didn't get to these...)

1. Review on how to add things to board.
2. What are doing with the review items in the "Unknown Priority"?
3. Tackle the in-reivew items before new work. How do we distribute?
4. Review the in-progress items
5. Review the items that are blocked. Are we doing them now?
6. Review the unprioritized Todo items? Which can we defer?

Acctions

• @BigLep punt things out of scope
• Engineers: determine what doing with the "Todo: Unknown Priority" items

• We should only do items we believe we have to do this next month. Otherwise set to the next interaction.

• Anythign we are doing should have very clear done criteria. I should be able to come back and understand why we're doing it.

• Engineers: for the Blocked items, ensure we have to do them this iteration. If not, move them to the next. If we do, make sure the blocked reason is clear.

• @guseggert : ensure the Bitswap items and especially Add independent server implementation go-bitswap#567 have clear done criteria.
• Engineers: which of these PRs in review do we want to make sure get landed?

• Engineers: reminder that we're tackling the things in review before we move forward on our initiatives. If you think initiative work is more important than a certain PR, then we should likely be moving that PR to the next iteration.

  • Please move the items we aren't concerned about into the next iteration.

[BigLep]

2022-08-12 conversation with maintainers:

1. We need to land the release template issues early week of 2022-08-15.
2. We'll start the release process on Wednesday, 2022-08-17, during European timezones. Merges after this will make it into the next release.
3. Items we are attempting to land before...

• go-libp2p 0.21: feat: go-libp2p v0.21 (rcmgr auto scaling) #9074
• Blake3 feat: add blake3 support #9187
• Use the Bitswap client/server separation with the unifying polyfill (to test if we broken anything) Split server & client and create message dispatcher object go-bitswap#568
• Gateway interface feat: make corehttp a reusable component #9070
• FX plugin feat: add fx options plugin #9010

[BigLep]

Release mechanics/template items that should get finished before the release:

• Fix release template issues/gaps (v0.11 edition) #8576
• Close out Release v0.14 #9032
• Update RELEASE_ISSUE_TEMPLATE.md based on 0.14.0 release #9100
• Update PATCH_RELEASE_TEMPLATE.md based on 0.13.1 #9095
• Moar release docs #9153
• docs: elaborate on some git cmds for releasing #9024

[BigLep]

@ajnavarro : I populated the issue description with the latest release template and created #9201 for capturing improvements. Plesee update PR as you notice issues.

[ajnavarro]

Early testers ping for RC1 testing

• pacman.store (@RubenKelevra)
• Infura (@MichaelMure)
• Textile (@sanderpick)
• Pinata (@obo20)
• RTrade (@postables)
• QRI (@b5)
• Siderus (@koalalorenzo)
• Charity Engine (@Rytiss, @tristanolive)
• Fission (@bmann)
• OrbitDB (@tabcat)

[BigLep]

@ajnavarro : per 2022-08-22 conversation, we need to do the Stage 0 items as well.

Maybe it makes sense to not have the RC items in a separate list but rather have the checklist assume only 1 RC and make a note that certain steps need to be done for each RC.

[tabcat]

@ajnavarro I'm no longer maintaining OrbitDB. You can ping @aphelionz from now on unless he says otherwise.

[aphelionz]

@ajnavarro Happy to test with OrbitDB. WIll give it a go today

[BigLep]

Bifrost deployment issue: https://github.com/protocol/bifrost-infra/issues/2046