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

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).

Bạn thấy bài viết này như thế nào?: 
Average: 5 (1 vote)
Ảnh của Tommy Tran

Tommy owner Express Magazine

Drupal Developer having 9+ year experience, implementation and having strong knowledge of technical specifications, workflow development. Ability to perform effectively and efficiently in team and individually. Always enthusiastic and interseted to study new technologies

  • Skype ID: tthanhthuy

Tìm kiếm bất động sản

 

Advertisement

 

jobsora

Dich vu khu trung tphcm

Dich vu diet chuot tphcm

Dich vu diet con trung

Quảng Cáo Bài Viết

 
Hướng dẫn cách quản lý drupal.org issues căn cứ theo priorities

Hướng dẫn cách quản lý drupal.org issues căn cứ theo priorities

The drupal.org issues however don't lend themselves to supporting working on your priorities. Here are some options and tools I used so far that help solve this issue.

Hướng dẫn managing obsolete modules

Hướng dẫn managing obsolete modules

In every Drupal project, it is crucial for your application to be fully defined in code at every time and every state. 

TOOL SEO nên hay không nên qua 9 bài học sau

TOOL SEO nên hay không nên qua 9 bài học sau

ToolSEO có 2 loại: bán dữ liệu (Ahrefs / KeywordIO Tool…) hoặc giúp xử lý công việc hàng loạt + nhanh chóng (SERPLAB, Screaming Frog…)

Công ty diệt chuột T&C

 

Diet con trung