In a perfect world, organizations would be able to continuously update their software to ensure that it stays in sync with updates to programming languages as they evolve. In reality, however, updating your codebase to reflect version changes in programming languages is often easier said than done. 

Simply determining when codebase changes are necessary due to a language update, let alone implementing those changes, can consume tremendous time and resources. That’s why it’s important to define a process for:

  • When and how to upgrade your codebase.
  • How to deal with the inevitable End Of Life (EOL) announcement for the programming language(s) you depend on. 

Having a process in place ensures that you can make strategic rather than ad hoc decisions about the time and resources required to ensure your software remains secure, supported and usable. This post explains how to design such a process, and which factors to consider when planning an upgrade or EOL strategy for the programming languages you depend on.

How to Know When to Upgrade a Codebase

As research has consistently shown, codebases are rarely if ever updated because:

  • You may introduce a cascade of dependency upgrades that end up landing you in Dependency Hell.
  • Upgrades can introduce new versions of dependencies that may need to go through an internal review process to determine licensing compliance, maintainability, security, etc.
  • There’s a very high likelihood that any upgrade will end up breaking the build.
  • Time and resources are often better spent creating new features/functionality rather than on upgrades.

The reality is that there’s rarely a good business case to move from one version of a programming language to another. In most cases, your software will gain no significant new functionality, and certainly no new differentiated features if your competition is also using the same language. 

Typically, there are only two reasons to consider upgrading to a new version of a language:

  • The upgrade provides fixes to one or more critical issues, including security vulnerabilities and/or critical bugs.
  • The current version of the programming language is being EOL’ed.

But that doesn’t mean you can abdicate your responsibilities and ignore upgrades. You still need to have a process in place to:

  1. Assess the new version of the programming language for capabilities, and whether it addresses key security/bug issues.
  2. Whether it affords backward compatibility, or introduces breaking changes.
  3. Whether the support status of the language version you’re currently using has changed.

Depending on the answer to each of these questions, you should be able to gauge whether an upgrade is necessary, whether it will likely pose a problem, and when to start planning. 

What Does End-Of-Life Mean for Programming Languages?

In the context of programming languages, EOL represents the date when developers of a language will cease offering official support for it. Languages that have reached their EOL dates no longer receive new features or functionality, but more importantly, they no longer receive updates that resolve security vulnerabilities or fixes for bugs to correct performance issues.

To be clear, EOL status typically doesn’t mean the programming language as a whole is no longer supported. Rather, EOL dates correspond to specific versions or releases of a programming language. For example, Python version 3.7.13 will reach EOL status on June 27, 2023. Newer versions of Python will continue to be supported after that date, but Python 3.7.13 specifically will no longer be supported.

EOL dates vary widely between programming languages and releases. Typically, EOL dates are announced years in advance, and they are noted in documentation files. You can also refer to community-maintained sites like endoflife.date to search for EOL information.

How Do EOL Dates Impact Applications?

Just because the programming language in which you built your application is now EOL doesn’t mean your software will suddenly stop working. Technically speaking, it’s usually possible to continue running applications for years beyond EOL, just like you can run Windows XP today despite the fact that Microsoft stopped supporting it nearly a decade ago.

However, both business and technical risks continue to increase the longer you run the application beyond EOL. Some of those risks include:

  • Security Threats: Because the language will no longer receive patches for security vulnerabilities, your application could be subject to cyberattack. This differs from security vulnerabilities that bad actors can target in supported languages in the following ways:
    • With supported languages, speed is paramount as bad actors have a narrow window before a patch is released. For this reason, attacks are typically less sophisticated because there is less time to create tools and scripts to exploit the specific vulnerability.
    • With unsupported languages, attacks tend to be more sophisticated, employing better tools and scripts designed specifically to target known, older exploits.
  • Performance & Stability Risks: Significant bugs can crop up well after EOL that may impact performance, compatibility with newer versions of an OS, or even stability, such as can occur with memory leaks. With no fixes forthcoming, you may have trouble keeping your application running.
  • Unsupported Interpreters: If you are using an interpreted language like Python or Perl, there is a chance that the latest interpreter may no longer support the running of your application. While you may be able to Install an older version of the interpreter on a modern version of an Operating System (OS), doing so may leave you dependent on an unofficial or non-supported interpreter, which could itself be subject to security or performance risks.
  • Compliance Risks: Although no major compliance framework explicitly bans EOL languages, many compliance frameworks do require organizations to undertake “reasonable” efforts to keep their software secure and up to date, such as PCI-DSS. Auditors may interpret EOL languages as a violation of this principle, leading to compliance headaches.

Thus, while it may be technically possible to continue running an application that depends on an EOL language, doing so is far from ideal. And the longer you keep using an EOL language, the higher your risk of experiencing a security, performance, or compliance problem. 

Programming Language Upgrade & EOL Best Practices 

If you’ve decided you can live with the risks and want to continue running your application beyond EOL, there are really only two options (this is also true for upgrades):

  • DIY: Bite the bullet, and dedicate internal time and resources top the issue
  • Outsource: Make it someone else’s problem

If you choose the DIY option, you will need to dedicate extensive time and internal resources to deal with:

  • Upgrades: rebuilding your runtime environment, and navigating all the issues that may arise. 
  • EOL: either:
    • Rewriting the application in a new language/new version of the existing language.
    • Creating a process to track and identify security issues, and commit to establishing (and retaining) the expertise in-house to fix them.

If you choose the outsource option, you will need to find a reliable partner and budget for their services, which should include:

  • Managing your runtime environment on your behalf, and/or fixing security issues/bugs as they arise. This can free up extensive time and internal resources, but you will still need to verify the upgrade/fixes via your CI/CD routine to find and resolve any issues that may arise with your proprietary code.

While upgrades can typically be handled as and when they occur, ideally, you will want to explore EOL options well before the EOL date for your language so you can make informed decisions and allocate resources accordingly.

To systematize the process, consider reviewing your current language dependencies and checking their EOL schedules at least once a year. You may also want to devote an internal documentation page to language dependencies and corresponding EOL plans so that you can see at a glance which EOL dates are approaching and whether you’ve addressed them.

Conclusions

No matter how you approach it, programming language upgrades and EOL deadlines are a challenge. Neither of them have to become a serious security, performance, or compliance risk for your business, however, as long as you plan ahead. If so, there’s no need to abandon revenue generating applications regardless of the official EOL status of its underlying programming language.

ActiveState has been providing extended support for aging and EOL languages for decades. We help our customers upgrade and manage their codebase, freeing up their internal resources to work on value-add features/functionality rather than managing their open source languages. Our services include:

  • Managed Distributions
    • Dependencies from our catalog of third-party dependencies are vetted to ensure security, maintainability and appropriate licensing according to your corporate guidelines. 
    • Runtime environments are securely built from source code (including native libraries) using your set of required dependencies for your project.
    • Runtimes are packaged for all target operating systems, ensuring reproducible environments that contain only dependencies that work together.
    • Optionally making your built dependencies available via our artifact repository for easier management and distribution.
    • Dependencies are monitored for vulnerabilities and stale-datedness; forks with updated dependencies are created, ready for you to take at any time.
    • A catalog of dependencies and transitive/OS dependencies are maintained over time so you can always reproduce the build.
  • EOL Language Support
    • Support is provided for Windows, Linux, macOS, AIX, Solaris and legacy operating systems.
    • Technical support is available via phone, email and chat.
    • Vulnerabilities are addressed with backported patches, community contributors, and our own language experts. Bugfix releases are also provided as needed.
    • Supply chain security is part and parcel of the offering, ensuring all dependencies are securely built.
    • Migration assistance is also available.

Next steps:

Want to understand how the ActiveState can help you manage your open source language upgrade and EOL needs? Contact Sales. 

Continue reading: