[meta] [proposal] Change to the release process

[colby-swandale]

I want to propose a change to the way we release versions of Bundler that will help ease some of the complexities for maintainers/release managers.

Current Problem

The process of making a release in Bundler requires the release manager to cherry-pick every change from the master branch into the stable branch (currently 2-0-stable). This applies for any new release being made. This process is can be quite tedious and consumes a lot of time for a release to be prepared. There are some other issues as well:

• Sometimes a bad cherry-pick will happen, resulting in a broken feature/fix Actually switch the default behavior of github sources. #6911
• Releases will quite often require a fair amount of time to fix breaking specs e5773b
• Merging changes from the stable branches back into master can often (especially for major/feature releases) take a long time. Move on to bundler 3 #6957
• PRs that are not either new features or bug fixes will often not make it into the stable branches, which is creating a big code difference between the 2 branches (ie: git diff master )

The proposed solution

My idea to help improve releases is to basically follow a similar process that other projects like Rails' use.

Patch release

For patch releases, the process will remain the same as it currently is. Cherry-pick fixes from the master branch into the stable branch.

Minor Release

When a minor release is being prepared, it should be prepared in the master branch. When releasing a minor version first make a commit/PR to bump the version to the next minor pre-release version and then follow the minor release guide

Note that pre-releases will be released from the master branch. Only after the stable release of the new minor version has been pushed to rubygems.org, would the stable branch be created and pushed to Github.

Major Release

Major releases follow pretty much the same way of minor releases. There will most likely be some changes that need to be made when bumping the Bundler::VERSION .

Bundler::VERSION

The bundler version in master should be whatever the latest minor/major is (including pre-releases). Patch releases versions would be set in the stable branches.

Example: At the time of writing, the latest version of Bundler is 2.0.2 , so Bundler::VERSION would be set to 2.0.0. Then once I start working on the 2.1.0.pre.1 release, I would make a commit to bump the version.

Final thoughts

This change should not be difficult to adopt as breaking changes in Bundler are now behind feature flags, which makes it possible to add new features & breaking changes, whilst maintaining our strict backwards compatibility to users.

This change in process will help reduce most complexities that i've listed above by:

• Eliminate the need to cherry pick individual commits from the master branch into the stable branches when preparing major/minor releases.
• Reduce the difference of code between with master and the latest stable branches. This should make tests fail less & require less fixes required for a passing test suite.
• Reduce the changes made in releases that need to merged back into master (It should only be the Changelog)

Bundler 2.1 would be a good release to release from master instead of from the 2-0-stable branch.

Let me know of any thoughts.

[segiddins]

Minor releases always were prepared off of master when I was doing releases?

[colby-swandale]

Yea, you're right. The RELEASE document pretty much already covers of what i'm talking about.