Stephen Kirby

Product Manager

<p>Recently, we’ve had many requests for guidance on when to upgrade a Coder deployment. When a new Coder release comes out, should you upgrade?</p>

<p>In the past, we’ve cut minor releases ad-hoc roughly monthly depending on the demand for in-progress features and the velocity of our engineering team. These releases were always cut from our main code branch with rare support for older versions and few guarantees of stability. We understand this introduces some ambiguity on what version is safest to use. </p>

<p>To remedy this, we’ve introduced a <a href="https://coder.com/docs/v2/latest/install/releases" target="_blank">new release process</a> that establishes a strict monthly <strong>release date on the first Tuesday</strong> of every month and separates new versions of Coder into mainline and stable release channels.</p>

<h2>Mainline and stable releases. Which should you use?</h2>

<p>Our mainline releases are intended for OSS community users and enterprise users with staging deployments who want the absolute latest coder features. These are fielded publicly for a month before we promote them to stable. </p>

<p>Stable releases, as the name suggests, are intended for large enterprise deployments with little tolerance for fault. This remains the default path for all installation methods excluding our <code>install.sh</code> script.  </p>

<p>On the first Tuesday of every month, we’ll cut a new minor release as “mainline” and promote the previous minor release to “stable.” Both of these versions will be supported in patching major bugs, security vulnerabilities and regressions. Thus, we’ll support each Coder release for exactly two months.</p>


An example of Coder release process from April. The mainline release channel is pictured in pink, and the stable channel in blue. As shown, we support both channels with patches as-needed to ensure stability in mainline once it’s ready for promotion.

<h2>What does this mean for your team?</h2>

<p>We hope this increases confidence in the stability of new Coder releases and offers clear guidance on when to upgrade your deployment. Defining a strict schedule should allow you and your team better anticipation for feature delivery and time to plan for updating Coder.</p>

<p>For enterprise customers, we advise updating Coder to the stable release routinely to avoid encountering old bugs, take advantage of new performance improvements, and maximize alignment with our support team.</p>

<p>If you have a problem on either release, please continue to reach out and we’ll be happy to get out a patch for any blocking issues. </p>

<h2>How does this impact installation?</h2>

<p>To increase adoption of the mainline coder release on clients, we’ve set it as the default path for our <code>install.sh</code> script. All other means of installation will default to our latest stable release. However, we <em>always</em> recommend explicitly defining a version from our Github releases when updating your control plane.</p>

<p>For more information about our release channels and schedule as well as future updates to our process, see our releases page in the <a href="https://coder.com/docs/v2/latest/install/releases" target="_blank">documentation</a>. </p>


We’ve had many requests for guidance on when to upgrade a Coder deployment. When a new Coder release comes out, should you upgrade?

When to anticipate new coder versions

Coder Release Channels and Schedule

<p>Looking at media accounts from KubeCon EU, you might get the idea that people who attended were focused solely on <a href="https://www.infoq.com/news/2024/04/keynotes-kubeconeu-2024/">Generative AI</a>, <a href="https://www.forbes.com/sites/justinwarren/2024/03/20/open-source-grows-up-at-kubecon-eu/?sh=75d59cdd583a">open source computing</a>, and <a href="https://siliconangle.com/2024/03/21/sustainable-cloud-computing-innovations-strategies-kubeconeu/">sustainability</a>. These were, of course, huge topics at the show. They seem to be dominating most tech conversations, so it’s no surprise that they’d be front and center at Europe’s biggest annual show dealing with all things Kubernetes.</p>

<p>But the conference, which took place last month in Paris, generated plenty of illuminating conversations about other topics – like Cloud Development Environments. Our team had an interesting time learning about the differences in opinions and priorities from attendees depending on where their organizations were located - although the majority came from European companies. While walking the hall and working the Coder booth, we found that people were not only familiar with CDEs, but actually using them and exploring ways CDEs could benefit their organizations.</p>


<p>Other observations from the show? Security was, as always, top of mind for an overwhelming majority of the attendees. Platform engineering is becoming more important at more organizations. In particular, compared to the U.S., most European companies field in-house development teams and dev contracting seemed to be much more popular. Open source – no surprise! – is a popular topic at KubeCon. And if you’re going to dinner in Paris, make sure to choose a restaurant that serves escargot.</p>

<p>Here are some takeaways from KubeCon EU.</p>

<h1>CDE awareness is up – but implementation is spotty</h1>

<p>We came to the conference confident that people would be much more aware of what CDEs are and how they work than the crowds at past KubeCons. (Coder’s recently published <a href="https://coder.com/ebooks-and-reports/reports/cde-adoption-report">Cloud Development Environment Adoption Report</a> revealed 95% of participants are familiar with CDEs and 66% of large organizations are currently using CDEs.) We were right. Practically everybody who talked to us was either using a CDE or thinking about it.</p>

<p>Many said they built their own custom remote development platforms using Ansible scripts because their own internal security rules required them to self-host their CDEs. For many platform engineering teams that had to build developer environments from scratch, learning that Coder was available in a non-SaaS format opened doors for saving time and redundant work. Offering an alternative to SaaS presented these teams with an immediate way to try out open source CDEs without needing to build their own platform, where they were having trouble running certain developer tools and performing VS code extensions for applications like Code Pilot or Microsoft’s Code Completion.</p>

<h1>Platform engineering is quickly maturing</h1>

<p>Platform engineering was an important theme at the conference. There were numerous sessions focused on building internal development platforms, and at least eight vendors marketing specific platform engineering tools. The term even merited its own dedicated ‘Platform Engineering Day’ at the BackstageCon event co-located on the same site.</p>

<p>One of the <a href="https://colocatedeventseu2024.sched.com/event/1YFjr/how-did-backstage-make-500-developers-happy-in-a-highly-regulated-enterprise-thomas-gronbaek-bankdata-as">Backstage</a> talks summarized how platform engineering has changed its focus and grown over the past decade. In the 2010s, people saw platform engineering as a way to improve developer productivity and save clicks. Now it takes on more of a security focus. Just like with DevSecOps, security best practices and features are being built right into the platform in the beginning of the process. This becomes yet another way to promote the importance of platform engineering while also improving an organization’s security posture and its developer cognitive load.</p>

<h1>Security is still top of mind in software development</h1>

<p>In conversations at the KubeCon booth, it was clear security has a significant influence on buying decisions in the developer ecosystem, even more for those security solutions with self-hosted capabilities. In the Cloud Development Environment Adoption Report, developers said <a href="https://coder.com/blog/cdes-provide-security-benefits-to-both-organizations-and-developers">five out of every ten CDE tools</a> were most frequently rejected due to a lack of security features. In the survey, security ranked as the top consideration when selecting tools, with 43.9% of respondents indicating it as a key feature when selecting CDEs.</p>

<p>At Coder, we see our CDE solution as a “security first” offering. We always argue that productivity and security aren&#39;t mutually exclusive, and if you start thinking about them in a siloed basis, like you’re solving one or the other, your overall environment will suffer.</p>


<h1>Dev contractors are common in Europe</h1>

<p>While development conferences in the U.S. draw larger numbers of in-house developers, dev contractors seemed to outnumber their in-house counterparts at KubeCon EU. Contractors we saw were particularly active in public sector and banking. Many worked for small consulting teams contracting with individual departments in banks or at specific agencies in one of the EU countries.</p>

<p>This opened the door for lengthy discussions about the benefits of CDEs in these organizations which require developers to frequently and seamlessly transition across projects. The onboarding process at these consulting firms is not a one-time cost for developers, rather a constant overhead that only scales with their success.</p>

<p>Consultants are most effective when they can quickly move between contracts without the friction of rebuilding their environments for each opportunity - this is where CDEs shine.</p>

<p>In our <a href="https://coder.com/ebooks-and-reports/reports/cde-adoption-report">CDE Adoption Report</a>, we concluded from customer data that CDEs can save 40 hours of onboarding time per developer by eliminating their environment setup. Cycling in teams every few weeks or months, organizations can save thousands of dollars per developer and streamline project flows significantly just by pushing development environments to the cloud.</p>

<p>Support for open source and open standards</p>

<p>Did we mention that KubeCon EU naturally was a draw for open source evangelists?
Countless times during the four-day conference people expressed a visible sign of relief when we talked about Coder being an open-source tool.</p>

<p>But the support didn’t end there. They also embraced Coder’s commitment to open standards – the fact that we work with all the major IDEs and with developer portal provisioning tools. Coder is proud to support both Terraform and OpenTofu for provisioning, and will continue to stay unopinionated in what tools developers wish to support. </p>

<p>To learn more on the survey findings mentioned above, check out our CDE Adoption Report <a href="https://coder.com/blog/cde-adoption-report-cloud-development-environments-the-next-frontier-of-programmi">here</a>.</p>

<p>If you’re interested in meeting the Coder team at an upcoming industry event, see where we’ll be <a href="https://coder.com/newsroom?page=1&newsType=Events">throughout the year</a>!</p>


<p>Related Content </p>

<ul>
<li><a href="https://coder.com/webinars/introduction-to-cloud-development-environments/register">Introduction to Cloud Development Environments</a></li>
<li><a href="https://coder.com/blog/cdes-offering-improved-developer-productivity-and-experience">CDEs: Offering Improved Developer Productivity and Experience</a></li>
<li><a href="https://coder.com/blog/cdes-provide-security-benefits-to-both-organizations-and-developers">CDEs Provide Security Benefits to Both Organizations and Developers</a></li>
</ul>


In the fourth accompanying blog to our CDE Adoption Report, we dive into interesting findings from attending KubeCon EU 2024. 

AI-native Development

Secure Environments for 2,500+ Developers

Stephen Kirby

Explore the latest from Stephen

Coder Release Channels and Schedule

KubeCon EU 2024: CDE Implementation is on the Rise, and People Love Open Source

Related content

Using Claude Code with Coder Workspaces

Introducing Coder Agents

Self-Hosted Doesn’t Always Mean What It Implies