Proposals (Political/Workflow) #4160

Decouple modules from core release cycle

Added by Lorenzo Pisani over 3 years ago. Updated about 3 years ago.

Status:NewStart date:07/30/2011
Priority:NormalDue date:
Assignee:Lorenzo Pisani% Done:


Target version:Unscheduled


I want to propose a change to the way we release our official modules and to the convention everyone else should use for theirs. The current release cycle is not very maintainable in my opinion. I will just use ORM as the example module throughout this ticket.


1. Accumulating Deadlines

The more official modules we add, the more code we need to make sure is updated before we can release the next major version of Kohana. This means that for every module we have, there is a deadline to get all API changes done before the API lock for Kohana. While Kohana is getting ready to release the next major version, all focus should be on the core repository. A bug in ORM should not force us to put off the next RC release for Core.

2. Less Meaningful Version Numbers

Modules currently follow the same exact version number as core. This is very confusing because module versions only tell you what Core version it is compatible with. It does nothing to tell how much of the module has changed. ORM 3.3.0 might not have API changes from 3.2.0 but it could also be a complete rewrite or be completely unmodified. The version number does not explain this. Version numbers in modules should work the same way as they do in core. 3.major.minor.hotfix with a bump in the first digit for big rewrites.

Some of our more mature modules might not need API changes so decoupling the versions from Core would allow users to continue applying bugfix releases without worrying about possible API changes. This is especially true for the simple modules that are quite small and rarely change. Not all modules need as much attention as Core and not many of them will need to break the API every 6 months.

3. Slower Bug Fixing

If we find a major bug in ORM this is what has to currently be done:

  1. Fix the bug
  2. Release core version
  3. Release version for all official modules
  4. Release new Kohana package

This is obviously often put off until enough bugs are fixed across all official repositories to warrant a bugfix release. It's a lot of work, and if done too often, annoying for the community. Kohana users that aren't interested in the modules that got bugfixes would still be affected by this because seeing a bugfix Kohana release makes them want to upgrade.


Release module versions as they become ready. Some of them will keep releasing together with Kohana simply because that's how they are worked on. Others, will release quicker than Kohana because they are newer or smaller and there are simply more things to improve. Bugfix releases can come at any time depending on the severity or the amount.

Decoupling the modules will lead to much better development of them because they will be worked on in the same exact way Kohana core is instead of being worked on as sub-projects. Kohana doesn't release in sync with PHP, we take advantage of new PHP features as they become available. Similarly, Ubuntu doesn't coordinate releases with all the packages they provide. When PHP 5.4 becomes stable enough in Ubuntu's eyes, they will begin packaging it in the default Ubuntu distributions but they will never depend on PHP releasing anything on time. I believe we should treat our official modules the same way Ubuntu treats the packages it includes in its distribution.

Our kohana/kohana package can still happen once every 6 months. It would simply include the new core, along with any supported official modules. If people want to update one of the modules before the next package comes out 6 months later, or simply want to apply a bugfix release of a module, they replace the module with the updated version. This again, is identical to what you would do to apply a bugfix release of core to any existing project and seems very intuitive.

Along with this change, I think we should add a simple convention for specifying dependencies. Not just on other modules, but everything. PHP, PEAR packages, PECL extension, etc. I think a file is perfectly fine for this.

This new way of managing versions will definitely have pros and cons, so let's try putting together a comprehensive list before we make any final decision.


  1. More focused work on the core submodule before releases
  2. Meaningful versions in modules
  3. Quicker fixes to module bugs
  4. Can handle more official modules without slowing core development
  5. Mature/Simple/Unaffected modules don't need version bumps
  6. Merging pull requests from GitHub will be much easier


I will append whether it affects users or core devs.

  1. Users of the module need to make sure their dependencies are met (users)
  2. Packaging every 6 months becomes more work as the compatible versions need to be found (devs)
  3. It's not obvious, at a glance, which version of the module should be used (both)

I will continue adding to the lists as people discuss this ticket. I would prefer it not be closed until we have a solid list of pros and cons.

I would like to note that most of the modules will depend on a core version and possibly one more module. We don't have crazy dependencies so keeping track of 1 module dependency on top of the core dependency will not add a lot of work. This is why I think the pros outweigh the cons.

With a convention for specifying the module version, it would also be very easy to make a minion task to list all module versions with a simple command. This would allow people to quickly check versions before installing a new module.

Last note, I am not trying to create a package manager here. I don't think we need a package manager in order to decouple these version numbers.

Related issues

Related to Kohana Website - Feature Request #4164: Incorporating into the core website New 07/31/2011
Related to Userguide - Feature Request #3922: Add module conventions to the userguide Assigned 04/15/2011
Related to Kohana v3.x - Feature Request #4311: Module Requirments Closed 10/16/2011


#1 Updated by Kiall Mac Innes over 3 years ago

I like this idea, and I know its come up before .. so I'd just like to second "I would prefer it not be closed until we have a solid list of pros and cons."!

#2 Updated by Lorenzo Pisani over 3 years ago

  • Description updated (diff)

#3 Updated by Kiall Mac Innes over 3 years ago

  • Tracker changed from Feature Request to Proposals (Political/Workflow)

#4 Updated by Jeremy Bush about 3 years ago

  • Target version changed from v3.3.0 to Unscheduled

Also available in: Atom PDF