Project

General

Profile

Release cycle » History » Version 12

Yannick Warnier, 10/06/2015 19:37

1 1 Yannick Warnier
h1. Release cycle
2
3 8 Yannick Warnier
{{>toc}}
4
5 5 Yannick Warnier
In short, for each version, we do this:
6
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:
10
* Dev: ...
11
* Alpha: September-October 2013
12
* Beta: October-November 2013
13
* RC: December 2013
14
* Stable: January 2014
15
16
Details below of what each step means...
17
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.
27
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.
29
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
32
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 12 Yannick Warnier
h3. Roadmap availability
35
36
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. Roadmaps are all available here https://support.chamilo.org/projects/chamilo-18/roadmap, each in a subsection of its own.
37
38
h3. Testing
39
40
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.
41
Note for version 1.10.x: the current installation procedure for Chamilo 1.10.x is not possible to execute through Travis-CI. As a consequence, tests have to be run manually on developers installations until a solution is found (very tricky as the current base images for Travis do not include the possibility to have CLI PHP launched in version 5.4 or superior).
42
43 10 Yannick Warnier
h3. Major versions
44
45
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.
46
47
h3. Minor versions
48
49
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.
50 11 Yannick Warnier
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).
51 10 Yannick Warnier
52 6 Yannick Warnier
Between every two _versions_ of the software, there is a complete cycle of _releases_, which goes along the following...
53 1 Yannick Warnier
54 5 Yannick Warnier
h3. Development releases (nightlies)
55 1 Yannick Warnier
56
* Intended public: developers only
57 4 Yannick Warnier
* Feature freeze: large features are still allowed
58 1 Yannick Warnier
* Database structure freeze: changes are still allowed
59
* Database fields freeze: changes are still allowed
60
* Files structure freeze: changes are still allowed
61
* Can be used in production: NO
62
63 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.
64 1 Yannick Warnier
65
h3. Alpha releases
66
67
* Intended public: developers and regular contributors
68
* Feature freeze: large features are excluded
69
* Database structure freeze: changes are still allowed
70
* Database fields freeze: changes are still allowed
71
* Files structure freeze: changes are still allowed
72
* Can be used in production: NO
73
74
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.
75
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.
76 6 Yannick Warnier
77 7 Yannick Warnier
h4. Integrators add their code HERE
78 6 Yannick Warnier
79
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.
80
As such, it is safer and more time-saving to include these changes now.
81 1 Yannick Warnier
82
h3. Beta releases
83
84
* Intended public: any contributor
85
* Feature freeze: new features are *excluded*
86
* Database structure freeze: changes are *excluded*
87
* Database fields freeze: changes are still allowed
88
* Files structure freeze: changes are *excluded*
89
* Can be used in production: NO
90
91 2 Yannick Warnier
After a series of _alpha_ releases, the time comes to _freeze_ the structure of this version to focus on *stabilizing* it. 
92 1 Yannick Warnier
This means that we start reviewing *all* bug reports from all users, that have been reported on our tracking system (http://support.chamilo.org). 
93
94 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.
95 1 Yannick Warnier
96
97
h3. Release candidates (RC)
98
99
* Intended public: all users
100
* Feature freeze: new features are *excluded*
101
* Database structure freeze: changes are *excluded*
102
* Database fields freeze: changes are *excluded*
103
* Files structure freeze: changes are *excluded*
104
* Can be used in production: YES
105
106
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.
107
108
h3. Stable releases
109
110
* Intended public: all users
111
* Can be used in production: YES
112
113
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.
114 10 Yannick Warnier
115
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.
116 1 Yannick Warnier
117
h3. Promotion cycle
118
119
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!
120
121
h3. A new full development cycle begins
122
123
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":http://www.chamilo.org/irc right after a new version has been released. You will be surprised on how much you can influence the project.