Event Timeline
Draft for the new release strategy:
MITK release strategy
Based on previous experience, with sometimes very long release phases due to unresolved important bugs we wanted to include fixes to, and the understandable desire of users to get more stable access to the newest and shiniest parts of MITK, we are going to revise our release strategy to follow a more layered approach. We do not guarantee that every release will necessarily spend any (or equal) amount of time in each phase. We do however hope that the new system helps users to decide when to upgrade to a newer MITK version, and provides convenient tags for reference.
MITK release phases
Pre-alpha
This is basically the current master. There is no specific tag/branch or version denoting this state. We do our best to make sure the master is in a working state at any given moment, but please check our continuous integration dashboard before you decide to embark on building a specific commit. Expect frequent API and/or dependency changes as well as possibly major rewrites of large sections of code.
Alpha releases
Denoted by v<intended-release-version>-alpha. This will be available as a) a tag signifying the master commit the release branch was branched of from b) as branch <ReleaseTaskNumber>-v<intended-release-version>-alpha that development continues on. Please base any contributions you want to be included into the release on the alpha tag. We will not merge any branch based on a later master commit into the release branch.
At this point development is still going strong, but we will avoid updating any dependencies (ITK, VTK, minimum CMake/compiler version, etc.). Expect API changes and new features as well as bug fixes.
Beta releases
Denoted by <intended-release-version>-beta. Things have now settled down and we do not expect to add new features to the release. The alpha branch matures into a beta branch.
API should be stable barring any changes required to fix important bugs. API stability will take precedence before minor issues.
Release candidates
Denoted by <intended-release-version>-rc. Once the beta branch is stable enough we will create a release candidate branch that, in our opinion, is more or less done. Unless any critical bugs are discovered this will be the next release.
Testing
We try to prioritize bugs discovered during testing of the release branches. You can help us by including the relevant commit hash, ideally including whether or not the bug can be reproduced on the alpha-tagged commit. Please understand that bugs in the plugins and modules included in the binary installer releases take precedence.
Do we explicitly include the community to help finding and fixing bugs, once we defined a beta branch or a release candidate?
I was trying to aim for the middle-ground here. Yes, we want to include the community, because they know best what is important for them, which might not be entirely in line with whatever our focus is. On the other hand we can not promise that any fix for a specific bug will be included in a release even with help from the community, as past experience shows that larger bug fixes can have a slew of side effects, which are not always visible at first glance, and, as per the first point, the contributors tend to test only that part of the code that interests them.
I think both (@kalali and @goch) have a point and that it is no contradiction. We have to ensure, that no false anticipation, and therefor in the end disappointment, is generated. But this also holds true for the questions how thorougly we search for bugs (regarding our own man power and priorities and where other stakeholder must jump in, if it's important to them). So basically, I think, we should use the new release strategy to also clearly communicate "service level aggreements" and establish the possibility to assess the priorities.
With the release categories I am fine. But I think the release strategy should contain more. Let me try to draft it roughly in vanilla world.
Release strategy in Ralf's vanilla world
We have the following CI tools running:
- Dashboard/CI Testing of the master
- Dashboard/CI Testing of the release branch
- Dashboard/CI Testcoverage of the master (at least differentiated on per modul/plugin basis, and at least for linux)
- Dashboard/CI Testcoverage of the release branch (at least differentiated on per modul/plugin basis, and at least for linux)
- nice to have: Dashboard/CI Testing of reviews/contributions that might come into the release (no promise)
- nice to have: Dashboard/CI Testcoverage of reviews/contributions (at least differentiated on per modul/plugin basis, and at least for linux)
On top of that, we as stakeholder (MIC; SIDT; MICO)
- specify and communicate our priorities (s.b.).
- Communicate the service level aggrement for the priorities; e.g.
- We keep the dash board green. (which might also mean that we postpone or dismiss contributions if they are not well formed (make the dashboard red) and not within our priorities).
- We ensure sufficient high test coverage in parts of the code base (modules/plugins) we labeld as important for us.
- We do the checklists for releases for everythin we labeld as important for us.
- Communicate new release phases (if they are approaching) and a rough roadmap for the current release.
- Communicate that community/ other stakeholder have to jump in.
- Basicalle everywhere, where they have a higher priority, than we have, and wont to be sure, they have to join forces
- raise the code test coverage
- due checklists
- propose patches
- Basicalle everywhere, where they have a higher priority, than we have, and wont to be sure, they have to join forces
- Communicate that we cannot always promise fixes/contributions to be included (even so we try).
- Depending on the phase, some things are out of scope (e.g. no 3rd party changes in alpha, no new features in Beta...)
- If our priorities are violated (e.g. green dashboard, test protocols) and we cannot fix it in time, it might be postponed till after the releas
- If one want to hightend the chances for the contribution
- He should start to contribute/test/fix as early as possible appropriate to the current releas phase.
What are "our priorities"?
That has to be discussed. I am not quite sure yet; neither what nor how many priority classes (2 or 3).
But basically I would think about all modules/plugins we (e.g. MICO or SIDT) define as important. And for example (on a check list level) everything that goes into Workbenchreleases we provied.