What do you think of this module versioning strategy?

[bernhard]

I just pushed an update to my RockGrid module and came up with a new strategy for the module's version numbering: https://gitlab.com/baumrock/FieldtypeRockGrid/blob/master/FieldtypeRockGrid.module.php#L13-24

I placed a changelog file in the repo: https://gitlab.com/baumrock/FieldtypeRockGrid/raw/master/changelog.md

And then the module reads the first line as the version number:

'version' => fgets(fopen(__DIR__ . '/changelog.md', 'r')),

That way I just update the changelog with some comments, have everything in place and the module automatically updates the version number.

This is also handy to share one version number for all child modules (eg Fieldtype + Inputfield). I'm not sure about that one, though. Do you think it is a good or a bad idea to have one common version number for both the fieldtype + inputfield or do you think it would be better to have that separate. The concept of having a readme and reading the version number from there would not be affected.

[psy]

My thoughts FWIW... the dependent modules, eg Fieldtype & Inputfield version numbers should be in line with the module version number. To keep things consistent, if the dependent Fieldtype or Inputfield are updated, the module version should be updated too to alert devs of the change

 

[horst]

Hi Bernhard,

Q: .. and when the changelog.md has gone, (by accident of corse)?

The modules are PHP, why not using a PHP file and including this? I think with a PHP file, people will be more careful then with a readme, or changelog file.

  public static function getModuleInfo() {
      include(__DIR__ . "/version.inc.php");  // the inc.php contains a var $moduleVersionNumRockGrid, which holds the current version
      return array(
        'title' => 'RockGrid',
        'author' => 'Bernhard Baumrock, baumrock.com',
        'version' => $moduleVersionNumRockGrid,
        'summary' => 'RockGrid Main Module',
        'requires' => ['RockFinder'],
        'installs' => ['InputfieldRockGrid'],
        'icon' => 'table',
        'autoload' => true,
        );
  }

 

This way, you can style your changelog file to match @netcarver desired formats for programatically read those in.  ?

[bernhard]

Good point. Need to have a look at his module. Didn't try it so far ?

I wanted to make it supersimple but a PHP file would also be fine of courses. Thanks for the input!

[BrendonKoz]

(Assuming the suggestion is for a normalized way of handling versioning in changelogs for all modules moving forward.)

As much as I like the idea of using some dynamic method to keep a version number in check, I'm not sure that a changelog (or markdown file) is the best way to handle that - at least not by simply pulling the first line and expecting that it will contain the updated version number. There are many suggested ways of creating changelogs. (There's even a discussion about best practices mentioning some of those links.)

Since there are so many ways to handle changelogs (sometimes organization-specific standards) I'm not sure this could work for everyone in practice (esp. those that are using info.json files for this module data). I definitely think it looks like a terrific idea for your own use case though, and until I thought about it further I got all excited by the prospect! ?

I do think it's OK to have a fieldtype/inputtype combo that share the same name also share the same version number.

[dotnetic]

On 9/7/2018 at 1:20 PM, psy said:

My thoughts FWIW... the dependent modules, eg Fieldtype & Inputfield version numbers should be in line with the module version number. To keep things consistent, if the dependent Fieldtype or Inputfield are updated, the module version should be updated too to alert devs of the change

 

I agree with that.

[horst]

On 9/7/2018 at 1:20 PM, psy said:

My thoughts FWIW... the dependent modules, eg Fieldtype & Inputfield version numbers should be in line with the module version number. To keep things consistent, if the dependent Fieldtype or Inputfield are updated, the module version should be updated too to alert devs of the change

 

 

9 hours ago, jmartsch said:

I agree with that.

 

This will not work well together with a centralized (and included) version number. There are multiple possibilities to mix wrong files together. 

 

My personal conclusion is to keep the version number hard written in each class file, ( the old schooled way). ?

 

[dotnetic]

I meant this without using a centralized (and included) version number.

Just wanted to say that if either the fieldtype or inputfield should change, the version number should be updated in all of the modules accordingly, because I see them as a whole module package.

[horst]

36 minutes ago, jmartsch said:

 

I meant this without using a centralized (and included) version number.

 

Yep, I know. My comment was addressed to Bernhard and his main question in this thread. Sorry for being unclear.