Hi devs, During the last dev meeting [1] we talked about how we should manage the $VERSION var of our Koha modules. (a)The first idea was to remove it: it is stuck to an old version and it does not make sense to keep it as it. Another idea would be to keep it and use it (i.e. update it). This idea has already been discussed on bug 7941 [2], but never been set up. In this second approach, there are different ways to do, either we update all of our modules to the Koha::version or update them individually, when they change. Based on 2 blog entries [3, 4] and the Perl Best Practices (Chap 17: Modules, Version Numbers), the way to do would be to use a three-part version numbers ('1.0.3') using the version module (`use version; our $VERSION = qv('1.0.3');`). But there are no specific guidelines to manage the different modules inside a project. I have checked several perl projects and they don't assign a version to each modules (Dancer, DBIx::Class, Mail-SpamAssassin). (b)Set the same $VERSION variable to all our modules does not seem very useful (unless making `perlcritic -2` happy). (c)On the contrary it would make sense to version them individually, following the Koha::version: when a module is modified, the minor version is increased. That would be easy to do for stable releases: the version is updated when releasing. But for master we could have a module version > Koha::version (indeed the Koha::version is only updated when a DB entry is added). To avoid that we could decide not to update the version during the development process (master). (d)Another way to do would be to initially set the version to 1.0.0 (or 3.0.0 or whatever) to all the modules and increase the version when they are modified, but the version numbers would not make sense and won't be helpful: some unchanged modules will have 1.0.1 and others 1.2.34. I think (c) makes sense: for instance if C4::Budgets is not modified between 3.22.x and 3.24.x, its version will stick to 3.22.x. Looking at this version we would know if this module has been updated recently or not. Concretely, we would set all of our modules to 3.24.00.000 (not that does not respect the 3-digit and 3-part version numbers "conventions") when releasing 3.24 (scripts will provided to automate everything), 3.25 will come and won't update the module versions until 3.26. 3.24 RMaint will update the versions of the modified modules when releasing 3.24.01.000 3.26 RM will update the versions of the modified modules when releasing 3.26.00.000 Note that we could "back-versioning" the modules of all our stable branches (3.18, 3.20 and 3.22). What are your thoughts? Are you more a, b, c, d or ... e? Cheers, Jonathan [1] http://meetings.koha-community.org/2016/development_irc_meeting_1_march_2016... at 15:40:52 [2] https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7941#c2 [3] http://www.modernperlbooks.com/mt/2009/07/version-confusion.html [4] http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/