Support #6617

Updated by Julio Montoya about 6 years ago

I remember that we discuss about the possibilities to change the version number from new Chamilo LMS (master in github). says:

Given a version number MAJOR.MINOR.PATCH, increment the:

> * MAJOR version when you make incompatible API changes,
> * MINOR version when you add functionality in a backwards-compatible manner, and
> * PATCH version when you make backwards-compatible bug fixes.

So for Chamilo LMS we should embrace this standard.

Here are the current possibilities (feel free to suggest more)

h3. The current state:

1.9.8, 1.9.9 then *1.10.0*, *1.10.1* ... new big version *1.11.0*

This is wrong, because we are still in version 1!! This gives an impression that we are not moving on.

h3. The "natural" version order according to

1.9.8, 1.9.9 then *2.0*, *2.1* new big version *3.0*

We should do this, now that there are 2 different "products" in the Chamilo Association: Chamilo LMS and Chamilo LCMS. Chamilo LCMS has now version 3 (Chamilo LCMS Connect 3.1 Bradypodion Carpenteri) and version 4 (Chamilo LCMS Connect 4 Brokesia)!!

h3. New convention (get rid of "1.x"):

1.9.8, 1.9.9 then *10.0.0*, *10.1.0* new big version *11.0.0*

Not sure if you will agree with this.

h3. -New convention version number based in the *year*.-

-1.9.8, 1.9.9, then *14.0*, *14.1* *13.0*, *13.1* ... new big version *15.0* *14.0*

This force us to release at least 1 big version every year, but this was not the case in 2013.

The idea of 3 -and 4 is-:
- To get rid of the "1.x" prefix so people could easily remember "Chamilo LMS" + a version number and suggest that the project is evolving fast (which is the case).
- to manage better minor versions: 14.0 13.0 and 14.1 13.1 could include DB changes. But not DB changes from 14.0.1 13.0.1 to 14.0.2 13.0.2
- Having version like is now just ridiculous :) hopefully for version 1.9.x we stick to 3 numbers! :)
- By "big version" I mean database changes, folder restructure, new tools, etc.

What do you think??