Release cycle
- We release major and minor versions.
- Major versions can contain database and files structure changes.
- Minor versions cannot contain database or files structure changes.
- Major version usually contain numerous new features but due to their high variability of structure, they might bring new bugs too and definitely make upgrades more complex.
- Minor versions mostly bring fixes between major versions. Upgrade from a major to a minor version or from a minor to another minor of the same major version is usually much easier (overwrite files… Done!).
We are currently working on 3-numbers version: 1.11.0, 1.11.2, 1.11.4
- 1.11, or 1.11.0, is a MAJOR version.
- 1.11.2, 1.11.4, 1.11.6 are MINOR versions.
In the future, we will go back to 2-numbers versions: 2.0, 2.2, 2.4, 2.6…
We only use even final numbers for the minor versions (2, 4, 6, 8, 10, …) because it is a general agreement in versions numbering that even numbers add stability while odd numbers add new features (and so… some degree of unstability).
For any major release, we first release an alpha, then a beta, then possibly several RC (Release Candidate) versions. Finally, we release the stable version.
Minor versions might follow that cycle or might simply use part of the cycle (usually one beta version).
Chamilo is a free software developed by a community of companies, universities and voluntary people. Because of its flexible structure, it is very hard to be sure about the date any version of the software will be considered stable.
In the free software world, we publish a new version not when the marketing staff is ready, but when the software is ready.
As all contributors bring new ideas, new code is included in the software. Sometimes, it makes things a bit less stable or a bit less usable for a while, but together with your comments and opinions, it is then improved and made a real asset to all users of Chamilo worldwide (around 6 million people in 2013).
Everytime someone brings something new, we have to think about how to integrate it into Chamilo to avoid making the interface more complicated, we have to try a proof of concept, then integrate it completely and finally review it. This means every new idea makes things better, but increases the time of development. Sometimes we decide to postpone it to the next version, and sometimes we decide it is so useful to the community as a whole that we should integrate it as soon as possible, no matter what. This decision is taken by a very small (but open to new blood) circle of active developers.
This means we might estimate a release date based on the progress of the debugging and development of new features, but we can never be sure about the date it will be published.
Currently our release rate is about one release every 6 months. There are usually 4 minor versions for one major version, and you should get a new major version about every 24 months or so (at the current rate).
A release is the publication of a specific version of the software as a package that people can download and install, freely. We have a Release procedure established for every Chamilo package.
Although anyone can contribute to Chamilo LMS, eventually the code will be checked by one of the Official Developers, before it is integrated into Chamilo’s core codebase.
Code review will ensure the following:
- Code conventions are respected
- No new bug is introduced
- No security vulnerability is introduced
- No identifiable bug regression is generated
- No notable damage is caused to usability
Plugins are also integrated to the Chamilo Core, so they must be verified with the same strictness.
Security of the code and the development lifecycle is ensured by the following measures:
- Public availability of all code changes, allowing for public scrutiny
- SSL-based authentication procedures, preventing the introduction of malicious code by third parties
- Strict limitation of write access to the official code by only a restrictive list of Official Developers
In short, for each version, we do this:
Development (nightlies) => Alpha releases => Beta releases => Release Candidates => Stable Release
Current expected dates for these phases for Chamilo 1.10 are:
- Dev: …
- Alpha: September-October 2013
- Beta: October-November 2013
- RC: December 2013
- Stable: January 2014
Details below of what each step means…
Our roadmap is very dynamic, so there’s never a fixed roadmap for a release. Usually, the roadmap is updated at least once every 3 months. Legacy roadmaps are available here, each in a subsection of its own. New roadmaps are available as Milestones in the Issues tab of this project.
Although not covering the entire Chamilo code, automated testing is run on a regular basis through an integration with Travis-CI: https://travis-ci.org/chamilo/chamilo-lms/builds and local tests.
Major versions are those with only 2 numbers (or 3 numbers ending with a 0), like 1.9.0, 1.10.0, 1.11.0. These include a lot of new features, database changes and file structure changes. These require cautious upgrade, careful staging and to keep a close watch on what’s going on, but also come with a great load of improvements and are really worth the extra difficulty.
Minor versions are those with 3 numbers that don’t end with a single 0, like 1.9.2, 1.9.4, 1.9.6, 1.9.8, 1.10.2, etc.
These versions are dead-easy to apply as upgrade, as they don’t include any database nor files structure changes. This means that, to upgrade a 1.9.0 portal to 1.9.2, the only thing you need to do is to apply the new code on top of the old one. Done! (no migration, no database upgrade, nada).
Between every two versions of the software, there is a complete cycle of releases, which goes along the following…
- Intended public: developers only
- Feature freeze: large features are still allowed
- Database structure freeze: changes are still allowed
- Database fields freeze: changes are still allowed
- Files structure freeze: changes are still allowed
- Can be used in production: NO
These are rarely “released”, so to speak, but sometimes, when nothing is really ready yet and we are still working hard on how to give shape to our software, we might release a development version so that other occasional developers can help us out in designing the new version.
- Intended public: developers and regular contributors
- Feature freeze: large features are excluded
- Database structure freeze: changes are still allowed
- Database fields freeze: changes are still allowed
- Files structure freeze: changes are still allowed
- Can be used in production: NO
After a few months (generally after 4 months of development), we will decide that we have added enough major feature and that we want to structure things out. To show that we are getting slightly closer to a new version and to ask regular contributors to help us, we release alpha packages. Alpha packages are not to be used in production, they are only for testing.
Within the alpha cycle, new medium or minor features can still be added and database structure changes (new tables, new fields) are still authorized, although slightly frowned upon.
For integrators (i.e. organizations that provide Chamilo as a service) that have developed new features and want them to be included in Chamilo, this is the best time to do it, because the database is about to be fixed (in the beta release) but new features are still allowed and the core development team stopped making changes to the core’s structure.
As such, it is safer and more time-saving to include these changes now.
- Intended public: any contributor
- Feature freeze: new features are excluded
- Database structure freeze: changes are excluded
- Database fields freeze: changes are still allowed
- Files structure freeze: changes are excluded
- Can be used in production: NO
After a series of alpha releases, the time comes to freeze the structure of this version to focus on stabilizing it.
This means that we start reviewing all bug reports from all users, that have been reported on our tracking system (see “Issues” tab in this project).
We remove all major or medium issues, and try to reach a point where all previously known issues have been solved, to the possible exception of some that we cannot reproduce, or that we think would unnecessarily delay the release of the stable version.
- Intended public: all users
- Feature freeze: new features are excluded
- Database structure freeze: changes are excluded
- Database fields freeze: changes are excluded
- Files structure freeze: changes are excluded
- Can be used in production: YES
A release candidate means we are very close to the stable release. This is the last step before a stable release. During this (generally short) period, we leave the software for download and wait for a bit so that people can try it out and let us know if anything goes wrong. If you find a bug of any kind and report it to us, we’ll have it fixed before we move to the stable version.
- Intended public: all users
- Can be used in production: YES
This is the achievement of months of work (generally thousands of hours of work), where we finally release the new stable version to the world. If you have servers running the previous version, this is the time to upgrade. If you are installing new portals, you will see that we will have removed the previous versions from our listings and placed this new version online for you to download.
Note: to accommodate the need for exceptional last change life-saving fixes or features, we sometimes use an hidden underground hide-out trick: we add variables that should normally reside in the settings_current table as one-line variables in the configuration.php script. This way, anyone wanting to benefit from this feature before the next release can just enable that setting manually. These variables are later moved into the settings_current table for the following major release. This is true for beta, RC and stable releases.
Right after the stable release, we will generally spend a few months (some developers, but mainly the people involved in marketing and communication) promoting the new version of Chamilo. You will see (and you can contribute to) new blog articles talking about the new features, press releases explaining what you can now achieve with Chamilo, etc. This is a time where you can help more than ever. Even if you are not a developer, you can easily talk about how you use Chamilo. Make sure everybody you know learns something about Chamilo, be it only its existence as a free software e-learning project. If you do that, you will have contributed to the Chamilo project in a great way. No kidding!
Pretty much at the same time as people start to promote the new version, we start preparing the plans for the next one. This is a period where we have a few meetings, talk to users and customers, listen (more) to conference speakers talking about the future of education… and stuff. Our community inspires us and this is how we can release a better software. Speak to us right after a new version has been released. You will be surprised on how much you can influence the project.
-
Home
- Tools and sessions
- Quiz: Importing
- Releases
- Community support strategy
- Translation management
- How to report issues
- Development
- Integration