Proposal - Deal with modules versioning ($VERSION)
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/
Hi, On Wed, Mar 2, 2016 at 9:56 AM, Jonathan Druart <jonathan.druart@bugs.koha-community.org> wrote:
What are your thoughts? Are you more a, b, c, d or ... e?
I'm in favor of option a (remove $VERSION from internal modules) or option e (drop PERL12 outright, but don't necessarily bother to remove $VERSION from the existing modules). I take this position on the following basis: - we don't explicitly promise that C4:: and Koha:: provide a _public_ API - no, really, we don't; if we did, we would have been taking much more care about keeping function and method signatures stable the past decade - any third-party code that nonetheless relies on Perl modules in C4:: and Koha:: should just check $Koha::VERSION - if we want to provide a public API via a set of Perl modules, we're of course free to do so, but should then keep questions of API versioning segregated to a special namespace - in light of all of the above considerations, any of the other options requires effort that doesn't solve a particular problem Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
I would prefer to leave them as-is and remove them when you are working on a module. Spending much more time on it decreases the time we could spend on more important issues in the code. Marcel ________________________________________ Van: koha-devel-bounces@lists.koha-community.org [koha-devel-bounces@lists.koha-community.org] namens Galen Charlton [gmc@esilibrary.com] Verzonden: woensdag 2 maart 2016 16:46 Aan: Jonathan Druart CC: koha-devel@lists.koha-community.org Onderwerp: Re: [Koha-devel] Proposal - Deal with modules versioning ($VERSION) Hi, On Wed, Mar 2, 2016 at 9:56 AM, Jonathan Druart <jonathan.druart@bugs.koha-community.org> wrote:
What are your thoughts? Are you more a, b, c, d or ... e?
I'm in favor of option a (remove $VERSION from internal modules) or option e (drop PERL12 outright, but don't necessarily bother to remove $VERSION from the existing modules). I take this position on the following basis: - we don't explicitly promise that C4:: and Koha:: provide a _public_ API - no, really, we don't; if we did, we would have been taking much more care about keeping function and method signatures stable the past decade - any third-party code that nonetheless relies on Perl modules in C4:: and Koha:: should just check $Koha::VERSION - if we want to provide a public API via a set of Perl modules, we're of course free to do so, but should then keep questions of API versioning segregated to a special namespace - in light of all of the above considerations, any of the other options requires effort that doesn't solve a particular problem Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Well, they all can be removed with 2 sed basically. Ok let's keep them and remove them during the next 10 years :) 2016-03-02 15:54 GMT+00:00 Marcel de Rooy <M.de.Rooy@rijksmuseum.nl>:
I would prefer to leave them as-is and remove them when you are working on a module. Spending much more time on it decreases the time we could spend on more important issues in the code.
Marcel
________________________________________ Van: koha-devel-bounces@lists.koha-community.org [koha-devel-bounces@lists.koha-community.org] namens Galen Charlton [gmc@esilibrary.com] Verzonden: woensdag 2 maart 2016 16:46 Aan: Jonathan Druart CC: koha-devel@lists.koha-community.org Onderwerp: Re: [Koha-devel] Proposal - Deal with modules versioning ($VERSION)
Hi,
On Wed, Mar 2, 2016 at 9:56 AM, Jonathan Druart <jonathan.druart@bugs.koha-community.org> wrote:
What are your thoughts? Are you more a, b, c, d or ... e?
I'm in favor of option a (remove $VERSION from internal modules) or option e (drop PERL12 outright, but don't necessarily bother to remove $VERSION from the existing modules). I take this position on the following basis:
- we don't explicitly promise that C4:: and Koha:: provide a _public_ API - no, really, we don't; if we did, we would have been taking much more care about keeping function and method signatures stable the past decade - any third-party code that nonetheless relies on Perl modules in C4:: and Koha:: should just check $Koha::VERSION - if we want to provide a public API via a set of Perl modules, we're of course free to do so, but should then keep questions of API versioning segregated to a special namespace - in light of all of the above considerations, any of the other options requires effort that doesn't solve a particular problem
Regards,
Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Hi, On Thu, Mar 3, 2016 at 4:08 AM, Jonathan Druart <jonathan.druart@bugs.koha-community.org> wrote:
Well, they all can be removed with 2 sed basically.
Agreed, it wouldn't be a big deal to remove them in one fell swoop. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
See bug 16011 2016-03-03 12:45 GMT+00:00 Galen Charlton <gmc@esilibrary.com>:
Hi,
On Thu, Mar 3, 2016 at 4:08 AM, Jonathan Druart <jonathan.druart@bugs.koha-community.org> wrote:
Well, they all can be removed with 2 sed basically.
Agreed, it wouldn't be a big deal to remove them in one fell swoop.
Regards,
Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Le 02/03/2016 15:56, Jonathan Druart a écrit :
Hi devs,
During the last dev meeting [1] we talked about how we should manage the $VERSION var of our Koha modules.
[...]
What are your thoughts? Are you more a, b, c, d or ... e?
Cheers, Jonathan
Hi, Maybe this has been answered somewhere already, but what are the benefits of keeping C4/ and Koha/ modules' version "up to date" ? The only one I can see is for external tools that use Koha Perl API and want to check if they are using the right version. But they can check kohaversion.pl as well. As an another example, Bugzilla does not seem to have $VERSION in its modules. I think we should do the same. -- Julian Maurice <julian.maurice@biblibre.com> BibLibre
Greetings, I'm for: (a) removing $VERSION (except from Koha.pm, right?) and (e) removing PERL12 (something Galen mentioned) and (f) tweaking perlcriticrc for the koha qa test tools to ignore $VERSION (and similar variables) rule. I think it might be something like (haven't had a chance to test): exclude = Miscellanea::RequireRcsKeywords GPML, Mark Tompsett
Hi, On Thu, Mar 3, 2016 at 7:02 AM, Mark Tompsett <mtompset@hotmail.com> wrote:
(a) removing $VERSION (except from Koha.pm, right?)
Right. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
participants (5)
-
Galen Charlton -
Jonathan Druart -
Julian Maurice -
Marcel de Rooy -
Mark Tompsett