Skip to main content

An introduction to EVA releases

Over time, EVA has grown into an extensive set of applications and modules. Not all of these facets adhere to the same release schedule, this document should shed some light on these release 'drops'.

Release distinction

When we talk about releases, we make a clear distinction between EVA frontends and the EVA backend. All EVA frontends are released simultaneously in our four-weekly EVA Drop [X]. The EVA backend is updated every single week in our EVA Core [X].

This distinction is an important one, even outside the context of releases. This distinction means that we always talk about two individual versions; your EVA backend (core) version and your frontend version, e.g. POS version.

EVA Drops

Our EVA Drops contain all of our frontend applications;

  • POS
  • CFD
  • Companion
  • Admin 1.0
  • Admin Suite


All of these applications follow the same release schedule so we bundle them in one drop as far as documentation is concerned. Every release consists of five weeks:

Development (Week 1-3)

The first three weeks of the release are exclusively reserved for development. During these three weeks, we go nuts on the tickets that were prepared ahead of the release to make sure we deliver them in a timely manner.

Internal wrap-up (Week 4)

Ahead of the fourth week, we have a release candidate for all our applications. This is however, an internal release candidate. During the fourth week, we extensively test our release candidates, while also documenting all of the changes we made.

Customer wrap-up (Week 5)

Starting the fifth week (monday), we have a production releases for all our applications. We then hand them over to our customers, who then have one week to test them and provide urgent feedback. Any potentially breaking bugs can be resolved during this week. Anything that isn't breaking or reported after this week will not be picked up any earlier than in the next release. The monday after, the final build is released.

Week 5 coincides with week 1 of the following release, so the release is actually 4 weeks long.

How to request changes

For us to properly deliver development tickets, it’s important to gather adequate details and requirements at the onset so there is minimal (read: ideally no) guesswork later in a ticket’s lifecycle.

When creating a new ticket on your Jira board, reference these details below to help you create the best tickets ever. It's important to clearly communicate the why in your ticket and we'll handle the how.

Request timing

Make sure to request any changes the end of week 3, as monday week 4 is the final refinement session for the following release. Any requests made after this cutoff point will not be considered for the subsequent release.

Jira Ticket Templates

RFC (Request for Change) / Product Enhancement Template:

If you wish your EVA system had a fancy new feature that will make your job 10x better, or your business has new requirements, then use the below format when composing a Jira ticket:

  • User Story: briefly convey the broad end goal from an EVA user's perspective. Use informal and natural language to illustrate the topic.

      e.g. As a (specific user), I want (x), So that (y)

  • Current State: What is currently happening? Describe more details here. Functionality might be existing and needs to be improved, or the functionality may not exist at all and needs to be developed.

  • Future State/Business Requirement: What do you want the end result to look like?

  • Justification: What benefits will be gained once moved to the future state? I.e., savings on time/cost/resources? Extra context here can help propel the proposed work.

Example of a bad ticket

"users are reporting tha we need a cancel to open after pressing the Print button. They click on it and it doesnt shoe up so you have to prnit. The users also say the page is acting slow"

Notice how we are missing crucial details here including the specific user, application, and context of the button they’re referring to. We also see typos and unclear or incomplete sentences and thoughts. Additionally, we see a separate issue mentioned in passing: “..the page is acting slow”, which is different topic altogether.

Example of a good ticket

"Summary: As a store employee, I want to have the option to cancel the printing of an invoice so that I have the choice to not print if I tap the button by accident.

Currently: On our Store App, we can print an invoice for the customer. When we choose the Print button, it immediately prints, however, sometimes we (or the customer) may decide that we don’t want the invoice printed after we’ve tapped the Print button.

Future state: Upon tapping the Print button, we would be presented with the option to Cancel or Proceed with printing via a new modal window.

Justification: We now waste paper and have to reopen the invoice section to enter the customer’s email to send this way instead, which lengthens checkout time of the customer."

Notice the highly descriptive writing and clear request.

Bug Ticket Template

If a functionality in EVA doesn’t work as expected, then a bug ticket may be necessary. A bug ticket should include as many of these details as possible:

  • Description: Concise sentence explaining the issue
  • Impact: What will happen as a result of this issue? Users cannot log in? Data is incorrect? Bad user experience? Describing this will minimize push back or re-prioritizing the work.
  • Steps to Reproduce: List the step to recreate the issue. Include screenshots, GIFs, or videos (ideally in-line within the ticket).
  • Expected Result(s): What do you expect the outcome to be?
  • Actual Result(s): What do you actually see when you follow the steps to reproduce?
  • Resolution: Steps taken to fix the issue
  • Root Cause(optional): The reason why the issue occurred
  • Preventative Action(s): Steps that can be taken or improvements that can be made to avoid this issue in the future. For an improvement, a new ticket must be created and related to this ticket.
  • Email: Snippet from an important email, which is not available on the ticket
  • Notes: Any other relevant information

How to handle releases

Some of our products are updated automagically. Admin Suite, Admin 1.0, and Core are all web-based deployments, we handle those for you. However, we expect you to handle application releases yourselves.

POS, Companion and CFD are applications that need to be installed on your devices locally. We provide installation files every release. Making sure your devices are updated is your responsibility. Not updating applications can lead to two issues:

  1. Customers miss out on fixes and might experience and report issues that have already been resolved, resulting in unnecessary time and effort spent for support, strategic leads and the product teams.
  2. Applications interact with our web-based deployments. Older applications might not interact correctly with the latest and greatest web deployments, resulting in reported issues that no longer matter.

We are working on an infrastructural solution to block access to EVA for applications that are more than one release behind on schedule. This applies to applications like the POS, CFD, Companion and Admin, as well as SDK versions and services that include deprecated fields.

In doing this, we make sure our customers always operate on the latest-and-greatest software we have available, and prevent unnecessary load on our strategic leads, support team and product teams. In short; better, more scalable.

EVA Core

EVA's backend is under constant construction. Development on the EVA core can be viewed as a continuous stream of improvements, without a standstill. Every week, we take whatever has been developed that week and deploy it to all acceptance environments. There are essentially three types of environments you can have as far as Core is concerned;

Environment typeDescription
DEV/TESTLatest, but not necessarily greatest.
ACCSomewhat latest, almost greatest.
PRODNot really latest, but most definitely greatest.


This is where you mess around.

Development environments, sometimes referred to as testing environments, are updated multiple times a day. When our developers make changes, additions or updates to EVA Core, development environments are deployed soon after. Things might not yet work on development environments, but they always include the latest updates.


Testing, keep this one sterile, as close to your prod as possible.

When you've thoroughly tested new implementations or features on dev or test, configure them on acc, which is short for acceptance. Your acceptance environment is the checkpoint before moving new configuration into production. Because of this, you should make sure your acceptance environment is as close to a 'mirror image of your production environment' as possible.

Acceptance environments are updated every single week. Usually they are updated on Tuesday, the release notes usually follow the next day (Wednesday).


Following the above information, please note that when we drop core release notes, these exclusively apply to ACC, DEV and TEST environments at that moment. PROD follows later.


Your business runs on this one, do NOT mess around here.

Where ACC updates may vary in delivery times, we follow a much stricter schedule for PROD, which is short for production. Your production environment is the real deal, your live orders run through here and we need to protect this environment at all costs.

Production environments are updated weekly as well, on specific moments:

  • Regions EUW and ASE are updated the Monday after ACC is updated, at 22:00 Amsterdam local time.
  • Region CUS is updated the Tuesday after ACC is updated, at 10:00 Amsterdam local time.