Skip to content

Latest commit

 

History

History
51 lines (30 loc) · 2.62 KB

release-process.md

File metadata and controls

51 lines (30 loc) · 2.62 KB
Raw

Title

Standard Release Process and Published Artifacts

Patlet

Teams may be reluctant to use InnerSource projects that they are unfamiliar with when there is no clear release process apparent in the repository. Providing clear release notes and a published artifact (binary, docker image, jar, etc) gives people confidence you are publishing a quality product.

Problem

When a team is deciding whether or not to use an InnerSource projects, one of their considerations is whether they trust that they can rely on the given project for an extended period. Switching the tools/projects that they are using has a cost, so they only want to make those investments sporadically.

It reduces trust if the given InnerSource projects doesn't have a published artifact or publicly viewable release process, as the team won't know when they can expect new features or the next release, how breaking changes are handled, etc.

Context

It is common practice in Open Source projects to have releases, with release notes documenting breaking changes, new features, etc along with either a published binary or link to a Docker image. This practice may not be as transparent or well documented/visible for InnerSource projects, modules, etc. Providing robust release notes along with a published artifact that is the result of a clearly documented and visible release process builds trust and confidence in your project.

Forces

  • Difficult for organizations that don't have a central CI/CD system
  • Adds the burden of publishing release notes
  • Becomes more difficult if the organization does not provide an internal location to host artifacts

Solution

  • CI/Delivery Pipeline is located within your repo to build artifacts (binary, docker image, jar, etc)
  • Releases and accompanying build artifacts are generated by CI system at build time
  • Release includes notes on New Features, Bug Fixes, and any "Breaking Changes" specifically called out

A good example of quality Release notes can be found here

Resulting Context

Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.

Known Instances

Comcast

Authors

David Grizzanti

Status

Initial - FYI we are considering splitting "Published Artifacts" into its own pattern