By donquixote


2019-04-14 13:49:18 8 Comments

By default, modules generated with features are created with a version string in the *.info file.

I think the convention is to increase this version number when the feature changes.

In a distributed development work flow with a lot of merging, a linear version increment is not a useful model or metaphor.

Is the version number, and incrementing it, useful or necessary for anything?

I work in a project where until now almost none of the features has version number. But recently a colleague reported problems reverting the features on deployment, if they don't have a version. Of this could be pure concidence, and caused by something other than the missing version number.

1 comments

@Shawn Conn 2019-04-15 17:11:25

It's metadata for keeping track of a Feature release. In D7, the use of Features has two cross purposes:

  • Bundling Drupal configuration up as a part of a released feature that can be deployed to any site (e.g. a bunch of re-usable content types).
  • Snapshoting config as code which is useful for capturing config that D7 didn't normally have (and has been supplanted by D8's config management system).

In the first case, the use of version tagging is more useful when you're a vendor of some project leveraging Features. A tag gives you an identifiable way to know what will be rolled back if you force a Feature back to its original state.

If you're using Features solely as config as code, versioning is not really important. Especially, if it's part of a large project that is already leveraging some release tagging.

@Shawn Conn 2019-04-15 17:11:30

Re: rollback, IIRC modules version property is optional. I do remember there are parts of Features (e.g. the export UI) that try to enforce having a non-empty version tag, but it doesn't have a concept of version control history for previous Features releases.

@donquixote 2019-04-15 17:14:55

And of course if you publish on drupal.org, you get the version tag for free from git release tags..

Related Questions

Sponsored Content

2 Answered Questions

[SOLVED] Export fields properly with Features

  • 2012-11-28 08:26:48
  • SavaryNicolas
  • 909 View
  • 3 Score
  • 2 Answer
  • Tags:   6 features

1 Answered Questions

[SOLVED] How to use features-export drush command?

  • 2017-01-27 21:36:20
  • user1359
  • 377 View
  • 1 Score
  • 1 Answer
  • Tags:   features

1 Answered Questions

[SOLVED] How to organize the features export modules

  • 2014-04-11 19:31:14
  • prabeen giri
  • 129 View
  • 1 Score
  • 1 Answer
  • Tags:   features

4 Answered Questions

[SOLVED] Export blocks with features extra

  • 2011-11-15 15:02:13
  • Michiel
  • 2746 View
  • 0 Score
  • 4 Answer
  • Tags:   blocks features

1 Answered Questions

[SOLVED] Features : export content types with FieldCollection

  • 2013-05-07 13:35:04
  • Alarid
  • 1192 View
  • 0 Score
  • 1 Answer
  • Tags:   features entities

2 Answered Questions

[SOLVED] export search_api settings with features

  • 2013-02-18 17:53:34
  • Andrew Welch
  • 1885 View
  • 2 Score
  • 2 Answer
  • Tags:   features search

0 Answered Questions

How to export CKeditor with Features

  • 2014-03-01 21:41:37
  • big_smile
  • 855 View
  • 1 Score
  • 0 Answer
  • Tags:   wysiwyg features

1 Answered Questions

[SOLVED] Export menu links with features

  • 2012-10-09 10:55:04
  • arrubiu
  • 6086 View
  • 4 Score
  • 1 Answer
  • Tags:   7 routes features

2 Answered Questions

[SOLVED] Export content in features using UUID features

1 Answered Questions

[SOLVED] Export multilingual settings with features

Sponsored Content