Release cycle
Currently Maintained for historic purposes onlyBika Open Source LIMS code is being re-engineered as Senaite for better maintainability and performance, under a more equitable brand and structure. The Bika Collective contributes generically acceptable code to the Senaite repos, and publishes lab discipline specific releases here as Bika Senaite add-ons.
Thank you for your patience. Team Bika
------8<-----------------------------------------------------------------------------------------------------
You are here: Home · Release cycle
Bika LIMS project developers are committed to release early, release often (RERO) in order to get more feedback from the user community and increase the quality of the system, both from technically and functional perspectives.
Minor releases are published regularly, ideally monthly, and only include bug fixes, small enhancements and test suites. Updating minor releases is safe and might not need further changes or modifications elsewhere in the Bika LIMS instance.
If the instance to be updated has been customised, you might need to review whether the customisations are affected by the update. This can be done by checking the CHANGELOG.txt file published with every release.
Major releases are published less regularly, ideally every six months and include new features, enhancements, bug fixes and new test suites.
Although the Bika LIMS development team is committed to allow backwards-compatibility and puts effort into solid migration scripts, upgrading to major releases might be risky. You need to review if the changes, new features or functionalities removed, suit your needs.
We highly recommend you thoroughly check the CHANGELOG.txt published with every release. Consider requesting access to a demonstration installation to evaluate the release before upgrading your instance.
Upgrading your customised instances could be tricky, and if not sure how the upgrade would effect your instance, we suggest to speak to any of the Bika LIMS service providers.
The minor releases are generated by merging the hotfix/next to master and if you fixed a bug, do a pull request to hotfix/next, including a description, or ideally, the Tracker Issue ID, and the output of the bika.lims robot tests.
Major-releases are generated by merging the develop branch to master and when you code new features and want to add them to the public repos, do a pull request to the develop branch. Like pull requests to hotfix/next branch, you have to include a description of the feature's Tracker Issue ID and the output of the bika.lims robot tests.
If you are developing new features for your instance and want them included in the release cycle, the best approach is to fork your own branch from bikalabs/Bika-LIMS' hotfix/next. Add your features/enhancements in the forked branch and it'll be available in your instance before its official release.
Thereafter, you do a pull request to the official develop branch for evaluation. If your pull request is accepted, your features will be published in the next major release.