bernhard

What do you think of this module versioning strategy?

Recommended Posts

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.

  • Like 3

Share this post


Link to post
Share on other sites

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

 

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 4

Share this post


Link to post
Share on other sites

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!

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 2

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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). 🙂

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.  

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.