Skip to end of metadata
Go to start of metadata

LExIM

As of mid-2016, the Core team announced a new strategy for CivICRM development and release management: LExIM

Why a new development strategy?

The core team and partners are always trying to improve the reliability of the CiviCRM software while continuing to innovate and develop new features.

The development strategy used so far was based on a traditional software development cycle based on major releases for the main branch of the software, and a community-maintained Long Term Support (LTS) for people wanting a stable and reliable version of the software. While this model has worked very well over the past 4 years, it had the drawback of having less users test new features in the main branch (since running the LTS), and developers frustrated because new features had a very long time before being included in the LTS. Release dates were also unpredictable, causing scheduling issues with service providers.

What does LExIM stand for?

LExIM stands for Leap by Extensions & Iterate Monthly. It basically means that:

  • CiviCRM development will now happen mostly through extensions, enabling the users to individually turn these new features on or off by enabling these new extensions,
  • Releases are going to be published on a predictable monthly schedule, facilitating planning and execution of regular updates by CiviCRM service providers.

More details are available on this strategy here (high level) and here (more details).

Monthly release cycle

CiviCRM releases are now published on a monthly release cycle. These releases are outlined in this calendar.

Each of these releases is managed as a project by a Release Manager (RM). The project plan includes:

  • Preparation - where the list of issues that will be included in the next release are finalized and summarized in a Google Spreadsheet. These issues are then grouped by topic.
  • Invite & registers - where the RM invites people to participate in the release process and people sign-up for participating. The participants indicate which topic(s) they want to work on, and teams are created around the topics. Each team should have at least one senior CiviCRM developer that will act as a mentor for the less experienced people on the team.
  • QA week - where each of the fixes for the selected issues are tested individually and validated.
  • Release Candidate testing - where the Release Candidate version, with all PRs merged, is tested by the Community. There is a Test plan for Release Candidate.
  • Triage of issues - where a group of volunteers goes through open issues in JIRA, and performs triage operations to validate that issue is real and correctly described, and assigns a target release version for the fix. This then feeds into the Preparation phase for the next release. There is a How to triage pending JIRA issues page describing this process.
  • Release - where the Release Notes are created (including the credits for the release) and the Release is published.

 

Labels
  • None