Release cycle » History » Version 10

Yannick Warnier, 19/08/2013 18:19

1 1 Yannick Warnier
h1. Release cycle
3 8 Yannick Warnier
5 5 Yannick Warnier
In short, for each version, we do this:
7 9 Yannick Warnier
Development (nightlies) => Alpha releases => Beta releases => Release Candidates => Stable Release
8 5 Yannick Warnier
9 6 Yannick Warnier
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...
18 2 Yannick Warnier
h2. General considerations
19 1 Yannick Warnier
20 6 Yannick Warnier
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. 
21 1 Yannick Warnier
22 6 Yannick Warnier
In the free software world, _we publish a new version_ not when the marketing staff is ready, but _when the software is ready_. 
23 1 Yannick Warnier
24 6 Yannick Warnier
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). 
25 1 Yannick Warnier
26 6 Yannick Warnier
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.
28 1 Yannick Warnier
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.
30 6 Yannick Warnier
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 12 months or so (at the current rate).
31 1 Yannick Warnier
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.
33 2 Yannick Warnier
34 10 Yannick Warnier
h3. Major versions
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.
h3. Minor versions
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).
43 6 Yannick Warnier
Between every two _versions_ of the software, there is a complete cycle of _releases_, which goes along the following...
44 1 Yannick Warnier
45 5 Yannick Warnier
h3. Development releases (nightlies)
46 1 Yannick Warnier
* Intended public: developers only
48 4 Yannick Warnier
* Feature freeze: large features are still allowed
49 1 Yannick Warnier
* 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
54 2 Yannick Warnier
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.
55 1 Yannick Warnier
h3. Alpha releases
* 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.
67 6 Yannick Warnier
68 7 Yannick Warnier
h4. Integrators add their code HERE
69 6 Yannick Warnier
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.
72 1 Yannick Warnier
h3. Beta releases
* 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
82 2 Yannick Warnier
After a series of _alpha_ releases, the time comes to _freeze_ the structure of this version to focus on *stabilizing* it. 
83 1 Yannick Warnier
This means that we start reviewing *all* bug reports from all users, that have been reported on our tracking system ( 
85 2 Yannick Warnier
*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.
86 1 Yannick Warnier
h3. Release candidates (RC)
* 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.
h3. Stable releases
* 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.
105 10 Yannick Warnier
Note: to accomodate 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.
107 1 Yannick Warnier
h3. Promotion cycle
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!
h3. A new full development cycle begins
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.