# New release model discussion

## Date: 18.08.2023
## Participants
* Schor, Stefan <[e-mail]>
* Hofmann, Matthias <[e-mail]>
* Wübbe, Marcus <[e-mail]>
* Menon, Ajaykumar <[e-mail]>
* Dederer, Christian <[e-mail]>
* Frömel, Florian <[e-mail]>
* Bajpai, Shashwat <[e-mail]>
* Mikone Nanay, Erzsebet (ADV D EU HU OPS 5 SOL 3) (EXT) <[e-mail]>
* M, Manohar <[e-mail]>

---
* Fabisch, Tobias <[e-mail]>
* Markl, Josef <[e-mail]>
* Salzer, Martin <[e-mail]>
* Wang, Xiao Gao <[e-mail]>
* Zhou, Jie <[e-mail]>
* Biro, Laszlo Attila <[e-mail]>
* Paroczi, Patrik <[e-mail]>

## High level thoughts

- Scaling
- Application development which depends on field-strength, system types, ...
- Hardware near SW which depends on concrete systwem types, platform, ...
- Collect images needed for FDA submission

- Feature Freeze
- R&D and stakeholders asseses during the feature freeze discussion the assumed feature content of the whole installed base.
- Goal: One feature set for the whole installed base
- We want to asses was has really have been achieved, if something does not work,
we want to move it to the next major version
- It is understood that we trade a common feature set across our portfolio higher than to be fast as possible.
- There are always features which are dedicated to specific system types / field strenths.
They are not really scaled to the whole portfolio.
Sometimes there are pure SW features which should be used for one system
(e.g. Smart-UI with eMeRge)
- The scaling of features would lead for some teams to reduced number of new innovations.
(1 innovation for the whole portfolio vs 2 innovations for just a part of the portfolio)

- How do we plan to collect feedback frequently? Will we've user base categorization - Collaboration sites?
- There is currently no plan to a increased collobaration (more updates, ...)
- It is of interest, but not on short notice

- How are service packs/service helps addressed who dont have latest software updated?
- The RM has a yearly cadence. This should also be the default for bug fixes for customer.
Do we need to be faster than this cadence?
- We can reuse a step 4 as bug-fix (aka service pack) for the systems of step 1
(but the time between is very short)
- the VB20A build does support a operation mode VB10 so that this version can be released as `NFJ` as VB10B (service pack for VB10A)
- Worst Case: Create a service pack like today (Service Pack M300 on the release branch of e.g. VB10A Step 1)
- Maybe there are improvements related to security patches possible, but maybe we stick to the current solution of deliver patches for the 90 day Security Deliveries

- Is there an architectural acceptance to take modularization on priority?
- Backward compatibility becomes more important with the new release model
- Prove/Optimize V&V that we not changed code for xxx if we scaled for yyy.
=> Modularization can help to reduce V&V and Test-For-Regression efforts by the simple fact that one module has not been changed at all

- Will customers accept the update frequency?
- Sometimes customers are waiting for new desired freatures (e.g. deep resolve)
- But this will not be true for every customer
=> we have to invest in customer communication (advantages, ...)
=> we have to invest in faster and more stable updates

- Business model should change over the time
- Every customer should get a software for free (bug fixes) but without extra customer features
- Advance-Now customer should get the software for free but also new customer value
- The difference between both must be clarified
- This approach would reduce the preassure to create service packs of a long period of time.

## What do we expect to be changed on day-day basis for IDP teams?

- Many more branches (short-lived)
- Many more builds - not well known team branches like today
- More full release pipelines executed for those branches
- One River night build with one release pipeline will change to multiple "full" builds per day and 3-4 releaes pipelines for those full builds
- Support shift-left activities - frequent performance tests, stability tests
- More and more tests will be developed which creates pressure towards IDP to be still fast with our builds
- Infastructure scaling should just be limited by the hardware budget, not engineers
- Evolve IDP to handle complete devops infinity loop (long term)
- Maybe we investigate solutions where not always all tests are executed

## What enablers (features) are required in the train?

- Invest for infrastructure as code
- Make maintaining of the infrastructure cheaper (more automation)

- Maybe we need tools to understand the changes between two versions of the mainline to derive which parts of V&V must be repeated

- Enable Monitoring of our infrastructure to proactivly improve
(e.g. more machines required, build becomes slower, ...)

- Invest in faster error investigations
(e.g. code change the reason for a build problem or an infrastructure problem (e.g. license server))

- Drop handling must be improved
(more dev branches leads to a lot of binaries on the drop, how to get the binaries removed?, ...)

- Monitor how long branches are active.

- Starting with VB20A, each build needs to be tested with two operation modes:
VB10 and VB20

In worst case;
Three operation modes: VB10, VB20 and VB30 => Three release pipelines

How do we support special long-term devleopment like Michelson?

- Build inside of containers
- Easier side-by-side support of different compiler verisons
- Easier to maintain
- Will be installed on demand, as required vs pre-installed globally

## What enablers (features) are required in other trains (e.g. other teams must contribute)?

## What else is required (non-features – e.g. how we do something, …)?

- Complete transition to git has also consequences for non-develoeprs:
Example: The cs number on formal documents. Maybe the PDP has templates with a change-set number in it

- Trainings needs to be organized
- How we use git with Numaris
(focus for our specialities like test-data, big repo, tools, ...)
- Feature Toggle handling -> Architecture Team

- Foster the change towards smaller and short-lived branches. Merge smaller batches.

- How to detect flaky tests (e.g. fit tests)?
Who is monitoring a FIT test across all branches?

- General approach how to handle flaky tests
(isolation, ...)