CMSMS LTS

[kishman155]

Hi,

i am module developer and have often the problem that the core get updated and i need to update all of my sites.
To update the websites is not the Problem because it's very easy with CMSMS.
But in the Past there are a lot of changes in Smarty, Module API, Content Type.

Wouldn't it be nice when there will be a LTS(Long Term Support) version of CMSMS with only Bugfixes?

It will be easier for Moduledeveloper to Update there Modules and the Core-Team will have more time for testing.

Then we get more save and fixed modules for LTS.
The Moduledeveloper have more time to fix there modules for the next LTS version.

This year there was allready 5 releases of CMSMS.

What do you think?

[totophe]

I think that before the LTS, we should have a professional support in place. I think that the release cycle is one main version per year and bugfixes during the year, but I might be wrong.

[chandra]

To the first LTS is a question of available manpower.

I don't no so much about the dev team internals but I think the manpower to support two CMSMS trees is not available.

But a possible way could be to involve module devs earlier in current CMSMS development. The idea behind this is sending a special developer newsletter to all forge project owners so they will have enough time to adapt the changes to their modules.

[Dr.CSS]

I believe every time there is a change that will break modules it is posted in Announcements before any release...

[Jos]

And I think the module API hasn't changed significantly over the last 3 years (I don't know before that) and if I remember correctly, I agree with Dr CSS that all changes have been announced in the forums long before release

[chandra]

I believe every time there is a change that will break modules it is posted in Announcements before any release...

Don't think all (busy) module devs will have time to read every announcement.

That's the reason for my suggestion to send a special newsletter .

[totophe]

Last week, at the Symfony conference, they explained how they do their versioning system and LTS. I find it really interesting and we should maybe adopt the same foundations (maybe it is already the case).

Basically:

1. Every maajor version number remove all the @deprecated functions from the API
2. Every minor version number add functionnalities
3. Every third version number only fix bugs and security issues

About the LTS, of course, we need the manpower to have it, aka some revenues for the foundation. Also, the way they submit bugs fixes and security fixes allow them to easily apply them to any supported version.

I know, the grass is always better on the other garden, but it is not a reason to not adopt new way to do things