Bundler release channels

[indirect]

As the developers of Bundler, we want to be able to continue to develop and revise Bundler into a better version of itself. As users of Bundler, we want the safest, most stable, least problematic version of Bundler at any given time.

Release channels are a way for the Bundler team to officially bless and support versions that have proven themselves to be stable. It also adds an easy and straightforward way to try the latest upcoming changes to Bundler at any time, increasing the chances that bugs can be found and fixed.

Bundler release channels allow users to opt in to the level of release stability that they want. The “canary” channel has a release from every commit that builds green. The default channel has regular releases when features and bugfixes are ready. The “stable” channel only has releases that have fixes for any issues found by the default channel. When possible, bugfixes are backported from the default channel to the stable channel.

Rendered RFC text

[colby-swandale]

I'm worried about how much more work this is going to be creating for us in terms of making releases often and keeping track of what changes are in what channel. No one on the core team is paid full-time to work on Bundler so trying to keep this idea running far into the future will be ... tough

This idea is also something that, to my knowledge, no other library is doing in Ruby. This is going to be a big new concept to introduce into the community and on selling them on the idea.

I'm also interested to know though on what will be the benefit to all this, we have a hard time asking people to test beta releases of Bundler, how will this improve on this issue?

[indirect]

@colby-swandale it will definitely be more work. I'm hoping we can make it extremely automated: canary builds ship straight from travis, and anyone can opt in by running gem install bundler-canary or something like that. Stable builds will require some additional release work, but again hopefully it means simply "checkpointing" an existing release that has proven itself stable, and copying that version to the stable channel. Combining both of those things means that I hope this would produce no more than, say, 5-10% more work for us as releasers.

The canary channel makes it easy for people to test a PR that was just merged—we definitely want to make it easier to give us feedback early if something isn't working, and expecting users to clone their own copy of the git repo and install a temporary copy of Bundler is too much work.

The other way that it helps us is more or less the way that it helps everyone else using this style of releases: most users are on the default channel. Existing feature releases usually spawn a flood of miscellaneous bugs. The stable branch is a way to get regular updates without having to worry about running into those relatively-buggy releases.

I hope that the stable channel will mean that Heroku and other platforms will be willing upgrade more regularly, after the bugs have been shaken out of recent release(s). Because Heroku etc. have so many customers, they are usually 1-2 years behind on Bundler releases. This is a way to offer them what they want (relatively bug-free Bundler) based on the work that we are already doing.

[hmistry]

I share the same concerns with @colby-swandale. If I understand this RFC correctly, I personally think this will add a fair amount of overhead in keeping 3 release branches appropriately updated with what is a very small dedicated team with little funding.

From the user side, I do not see much benefit because if I want to have the latest copy, I'll use the master branch or a pre-release version. If I want the default release, then I get the latest released version. And if I want to be on a more stable version, then I'd use one of the previous minor releases with patches.

I think part of the user contention between stable and updates is timing and quality. There was a phase when there were rapid releases for bundler, I think almost every week or so which was too fast and annoying IMO because there's no chance for a version to settle out and establish what I call a "released-and-used-by-many-without-major-issues" state.

Then there were some buggy releases and I understand it will happen. To me that's a QA issue and it means it's time to review the QA process or maybe spend more time verifying before releasing. This won't mean 100% bug free releases, but the goal is to reduce the failure rate to an acceptable level which you establish. The thing with bundler is at 20+M downloads, a 1% failure means 200K fails... so find your baseline.

Regarding new features: If you want users to try out new features, then how about doing alpha releases instead. Or like Safari Technology Preview where it can be buggy and no guarantee for feature to be released in next version update.

Regarding Heroku being 1-2 years behind, I think it's probably more due to their internal processes and feeling good about a release. I would try to understand their reasons because my presumption is they might wait for the dust to settle and then start vetting a release depending on whether there's a real need to update. Basically they will always be behind as they can't afford a mistake and I don't see this RFC changing that.

These are my thoughts on the matter and there could be things I don't see but none of the rationale presented so far convinces me for the team to take on the overhead this RFC proposes. I'd rather see that time go into QA or something.

[indirect]

Thanks for the feedback, @hmistry. As I mentioned to @rafaelfranca in a reply to his comment, the changes in this RFC are about smoothing the path for early adopters, which then smoothes the path for regular adopters, which then helps create a smooth path for the largest platforms that need the most stable versions possible.

Adding a canary channel will require some up-front work, but hopefully not any ongoing work. Adding a stable channel can reuse the work from canary. The added work then becomes carefully choosing an existing point release to copy to the stable channel, based on user feedback about bugs and stability. Since that should only happen once or twice per year at most, I think it's an acceptable amount of work if it gets us more user feedback and officially endorsed "stable" versions.

[simi]

I think the background for this case has changed and recently introduced "auto-installer" of locked bundler in Gemfile.lock is step in another direction.

I do have in my personal backlog to prepare "call to update" feature which can result in better promotion of newer versions. Once I'll collect all the info needed, I'll open RFC PR.

Speaking of today's state of Bundler/RubyGems does this RFC still make sense to anyone?

[indirect]

i think this situation is resolved by bundler version locking 👍🏻