JSM 1.0.0 Release Checklist: A Comprehensive Guide

Hey guys! Releasing a new version of a module can be a bit like navigating a maze, right? Especially when you want to make sure everything's top-notch before it goes live. This guide is your trusty map for the JSM 1.0.0 release, ensuring a smooth and successful launch. We'll cover everything from the minimum Jahia version to testing and publication checklists. Let's dive in!

:white_check_mark: Summary

Before we get started, here’s a quick overview of what we'll be covering:

1. Minimum Jahia Version
2. Testing Matrix
3. Prepare Checklist
4. Tests Checklist
5. Publication Checklist

Minimum Jahia Version

When it comes to the minimum Jahia version, it’s all about striking the right balance. We want to reduce deployment complexities by regularly updating the minimum Jahia version for our modules. Think of it as keeping the foundation strong so the house (our module) stands tall. When you're creating a Release ticket, it’s crucial to chat with your PM to pinpoint the new minimum Jahia version. The general rule of thumb? A new module release should play nice with the two previous Jahia releases. This ensures that most users can smoothly adopt the new module without needing a major system overhaul.

Currently, the Jahia version in our pom.xml is 8.2.1.0. For this release, we're aiming to maintain compatibility with Jahia version 8.2.1.0. This means we've tested and ensured that JSM 1.0.0 works seamlessly with this version. Why is this important? Well, it ensures that users on this version can easily upgrade to the latest JSM without any hiccups. It’s like making sure the new app you downloaded works perfectly on your phone’s current OS.

The process of determining the minimum Jahia version isn't arbitrary; it's a strategic decision. We consider factors like the adoption rate of newer Jahia versions, the features and APIs we're leveraging in the module, and the overall goal of providing a stable and consistent experience. By sticking with 8.2.1.0 for this release, we're prioritizing stability and ease of adoption for a large segment of our user base. Plus, it simplifies the testing process, allowing us to focus our efforts on the most critical aspects of the release.

So, remember, the minimum Jahia version isn't just a number – it's a commitment to our users. It’s about making sure they can confidently upgrade and take advantage of the latest features without worrying about compatibility issues. And that’s what makes a successful release, right? Now, let's move on to the next key step: testing.

:scroll: Testing Matrix

Let's talk about the testing matrix, which is super important for making sure our release is solid. Think of it as our roadmap for quality assurance. It helps us clearly document all the possible deployment scenarios and specifies which ones we need to test thoroughly. This way, we're not just testing blindly; we have a clear plan of attack.

Notes for Release Testing:

First off, great news! The CI (Continuous Integration) is green, which means our automated tests have passed. That's a big thumbs up! For manual testing, we’ll be focusing our efforts on Luxe. Luxe serves as our testing ground, allowing us to simulate real-world scenarios and catch any potential issues before they affect our users. It’s like running dress rehearsals before the big show.

Version Matrix

The goal here is to clearly document the possible deployment scenarios in a matrix and specify which ones are expected to be tested or not. This ensures we cover all bases and don't leave any stones unturned. In the testing matrix, we always use the latest patch version of a particular release. This ensures we're testing against the most up-to-date code and catching any regressions or issues that might have slipped in.

Specifically, we need to validate the following combinations:

• Minimum Jahia version (according to the pom.xml)

This is our baseline. If it doesn't work on the minimum supported version, we've got a problem. It’s like making sure a car runs smoothly on regular gas before testing it with premium.

:information_source: If you're releasing for the main branch of a module, make sure to complete the checklist below when working on the ticket. This checklist is our safety net, ensuring we haven't missed any critical steps. It’s like having a pilot's pre-flight checklist before takeoff.

The importance of a well-defined testing matrix can't be overstated. It’s not just about ticking boxes; it’s about building confidence in our release. By meticulously planning and executing our tests, we're minimizing the risk of surprises down the road. Think of it as investing in insurance – it might seem like extra effort upfront, but it pays off big time when you avoid potential disasters. Now that we've got our testing strategy in place, let's move on to the prepare checklist.

:pencil2: Prepare Checklist

Alright, guys, let's talk about the prepare checklist. Think of this as your pre-flight checklist before a big trip. It's all about making sure everything's in order before we hit the launch button. This checklist helps us avoid those