Nhìn lại các phiên bản Versioning trong Drupal

Versioning in Drupal

Currently Drupal has naming conventions for branches and tags in git for contrib module. These are based on the core version then the module version, for example 7.x-1.x would create a dev version 1 for Drupal 7, 7.x-2.3 would create a stable release version 2.3 for Drupal 7.

>> Giới thiệu the Content Preview System (CPS) trong Drupal

>> Giới thiệu Nginx Load Balancer Visualization trên Raspberry Pi Cluster

As we head towards Drupal 8 there has been a lot of talk about versioning for contrib. Core has already moved to using semantic versioning (semver), which is widely adopted by a lot of software now. Contrib is still on the old version numbering format. There is a lot of discussion about switching to something like semantic versioning for contrib. It’d be ideal to keep the core version somewhere in the number, there have been many suggestions, some of which are:

• 2.3.0-d8
• 2.3.0#d8
• 2.3.0@d8
• d8.2.3.0
• 8.2.3.0

My preferred, and it seems the favourite so far is 8.2.3.0, this is much like semver but the major version has been bumped down to make way for the core version, therefore core.major.minor.patch. The only possible issue here is if using composer for contib modules, composer will think the core version number is the major version number, and it will think the major version number is the minor version number. I feel that this is an ok compromise and we as developers can take this into account when using the syntax in composer.json.

Another versioning related issue is that we currently add the version number into the contrib info file as part of the packager that creates the module zip or tarball files. If more people pull modules straight from git (via composer) they won’t have this version number, causing the core update module not to work.

I say we should start asking module maintainers to add the version number to the info file. They already have to add the version number to the tag or branch, surely it’s no extra effort to add it to the info file, and saves so much effort trying to find a fancy programatic solution.

Update:

As part of this I have opened another issue on d.o to discuss how we can make update module work for modules installed via git (including via composer).