HIC SUNT LEONES
This is development version of midPoint. Although we try to keep midPoint in a good working shape through the entire development cycle, there are some fluctuations and unforeseen circumstances. This is development after all. Therefore proceed with care. Here be lions.
midPoint Development Snapshot is the latest build from the latest source code. It is the "HEAD" of the development. The bleeding edge.
Installing the Snapshot
Quality of the Snapshot
Quality of the snapshot varies depending on the development phase:
|Phase / milestone||Time period||Activities||Expected code quality||Recommended community participation|
|Feature development||start - feature freeze|
(usually 4-5 months)
|Development of new features.|
Restructuring, cleanup, architectural changes.
Fixing of important (subscriber, security) issues.
There are usually three internal milestones (M1-M3, M3 usually being feature freeze)
|No assurance about quality. Quality varies depending of specific feature. Nothing should be broken too badly - maybe except quite rare and usually very short intervals. |
Old features may be broken occasionally.
New features may not work at all.
|It may be worthwhile to check the stat of new features - especially for subscribers that are endorsing particular features. Look at the functionality, provide feedback, but please do not bee to pedantic yet. This is still work in progress.|
It is not recommended to systematically test all midPoint functionality yet. The bugs and unfinished part are perfectly normal at this point. Reporting them makes very little sense.
However, it makes sense to test the functionality of new features, especially at the milestones (M1,M2,M3).
This is ideal phase to contribute new features to midPoint.
You can also help improve the documentation of old features.
(M3 or M4)
|Old features mostly stable, but some bugs may be present.|
New features working at least for common positive cases. Bugs are still quite likely, but they should not be too bad.
|Start systematic testing of all midPoint features.|
|Testing and bugfixing||feature freeze - release|
(usually 1-2 months)
|Quality assurance (testing) and bugfixing.||Quality should be improving every day.||Participate in midPoint testing. Make sure midPoint works for your usecases. File bug reports and contribute fixes. Help improve the documentation of new features as the configuration schema should be perfectly stable now. Test upgrade and data migration.|
(Please see the explanation of bugfixing expectations below.)
|Production-ready||Use midPoint in production.|
The usual expectation is, that midPoint should work all the time, even in the most unstable phases of the development. There may be some glitches, unfinished functionality and so on. But nothing should be too broken to make midPoint as a whole unusable. If there is any risky development going on then it is usually conducted on a separate branch. Therefore master branch should be reasonably stable for development purposes - and in some cases even for pre-production purposes (e.g. developing a configuration for new features). But master branch is definitely not suitable for any production use. Wait for official release with that.
Feel free to try the snapshot. If you find that something does not work please review the list of current jira issues. If the issue that your are experiencing is missing from the list then go ahead and report it.
If you feel like contributing some code there is a list of "community" issues. Take any one of these.
For more details please see Development Participation page.
MidPoint is free and open source software (FOSS). MidPoint is developed in completely open environment and entire midPoint source code is available under the terms of open source license. This means that you can use midPoint for whatever purpose you like (as long as you stick to the license) and you do not need to pay for that.
But this does not mean you are entitled to get any support or that you can demand particular bug to be fixed. MidPoint is provided "as is", without any guarantees ... you know the drill. If there is a bug that you are hitting you have several options:
- Purchase midPoint subscription. In that case we will fix the bug for you. And we will do that quickly. Subscribers are prioritized.
- Fix the bug yourself and contribute fix back to midPoint project.
- Report the bug and wait. Please make sure that the report includes proper diagnostics. We will fix the bug eventually, especially if bugreport is good. But you need to be patient. Time available for bugfixing is limited and subscribers are prioritized. It is possible that the bugfix will be postponed to a next release.
Even though there is no guarantee that non-subscriber bugs will be fixed in the same release when they were reported, it may always be a good idea to participate in testing and create a bug reports. If there is a bug report then there is a chance that we will fix the bug. If there is no bug report then there is almost zero change that the bug will ever get fixed.
Just make sure that the bug report has all the necessary information. Make sure that it is filed in our bug tracking systems. But reports delivered through mail or mailing list are very likely to get overlooked.
Please also make sure that you are testing the right version of midPoint. Ideally test development version (master branch) between feature freeze and release. That's the period when your bug is most likely to get fixed. If you report a bug after release then it is almost certain that the bug will be fixed in the following release at the earliest. Which usually means you have to wait at least 6 months. Only the fixes for bugs reported by subscribers will be fixed immediately and applied to support branch. Community bugs will only get fixed on master branch - unless those are security issues or they affect almost all midPoint deployments. That is quite a strict policy. If you want special treatment there is a simple solution: subscription.