[Koha-devel] Proposal - Deal with modules versioning ($VERSION)

[Jonathan Druart]

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.2016-03-01-15.04.log.html
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/