Blog Documentation Book a Demo
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

The Great Release Sync

LincLinc Admin
edited July 2017 in Community Addons & Development

You may have noticed 2.4 is a bit late. This is in part due to a couple issues we discovered in it, most notably: https://github.com/vanilla/vanilla/issues/5709

We've also had challenges around addons branching.

Internally, we've been doing cloud releases very frequently, and we actually track 2 types of releases: public clusters vs. private, where the latter has a slower release schedule.

This used to make a lot of sense because we wanted to deliver small features & enhancements very quickly. As Vanilla has matured as a product & company, we now value large marquee features and the stability of our product much more than rapid releases.

We also recognize that running open source releases "on the side" has caused perennial delays. We were always reticent to let them be our primary release mechanism lest some esoteric Apache problem stop us from releasing our cloud product. I think those worries are years behind us at this stage.

Our real problem, currently, is managing up to 3 release branches in addition to master branch with a small team. Tracking patch backports & triggering different types of releases is causing a lot of communication overhead all around. The latest open source security incident can be directly attributed to this issue.

Starting with 2.5, our intention is for Vanilla to have a single unified release cycle internally and externally. As it goes thru the open source release stages, it will be incrementally deployed internally. Then we will manage that single release branch to add patches as needed. When we determine a patch needs to go to all our clusters, we'll increment the version a minor point and do an open source release as well.

We hope this gets us to a place where open source releases are extremely low-friction, and add more automation around them. There may be some unexpected bumps in the road, so we'll take it one step at a time. Currently, we anticipate a 2.5 release this fall centered around a new native API. We still intend to release 2.4 in the interim as soon as we're sure it's ready, and we understand its priority needs to get kicked up a notch.

I've already put a hold on further releases internally to start preparing for a synced 2.5 release. All patch backports now require a dedicated PR regardless of what release branch they target. Hope this works as well in practice as the idea in my head. :chuffed:

Comments

  • R_JR_J Admin

    That sounds really great! I always thought that whichever version is good enough to run your business should also be good enough to run open source forums :wink:

Sign In or Register to comment.