I agree with Marcel and Owen. I don't think it's a good idea to jump from version 3.x to 14.x, and I think version numbering is an important discussion topic, since it affects how Koha is perceived by current and future users. Having worked in libraries for the past 6-7 years as library staff and not a developer, I can state with a high level of confidence that consistency almost always matters more in libraries than software conventions; it is logically consistent that version 3 be followed by 4. Like Owen said, if that varies, there are going to be questions. While we might debate the merits of different version numbering systems, I don't think we're going to be the ones answering these questions in most cases. They're going to be aimed at trainers, salespeople, and technical staff who might not be developers. With the exception of Nicole, the majority of these people might throw up their hands and say, "I have no idea why it went from 3 to 14. It's weird." In many cases, no questions might be asked. In either case, people might just make negative judgements about the reliability, predictability, and transparency of Koha, especially if the "reason" for changing version numbering systems isn't made explicitly and readily available. Personally, I think it would make Koha look bad. The more often a Koha front-person says "I don't know" or "that's weird", the worse that person looks and the worse Koha looks. I think the growing consensus of software users, interface designers, and sellers is "don't make me think". It should be intuitive. That said, maybe I'm projecting a bit of my own biases. Maybe there would be some confused conversation about why Koha went from 3 to 14, but after the majority started using 14 and upgrading from there, it might not be an issue, because that idea of consistency would be regained. As for whether or not users and libraries even look at version numbers...I imagine that the vast majority of people interacting directly with Koha never notice them. They don't appear in the OPAC and in the staff client it's tucked away in the system preferences and About page. The ones caring are likely to be the ones who manage Koha in-house or the people who liaise with support companies. In these cases, maybe it would be easy enough to say, "Oh, the community just decided to change how it numbered each version", but I think this discussion will quickly be lost to time and the average Koha user/developer will have no idea why it changed and as Owen said...I imagine people might wonder if/what they're missing by going from 3.x to 14.x. For me, I think the most logical end to this discussion is to decide on a goal/trigger to switch to 4.x, and to just continue 3.x until that goal/trigger is reached. David Cook Systems Librarian Prosentient Systems P/L ABN 31 078 409 168 72/330 Wattle St, Ultimo NSW 2007 tel: 02 92120899 fax: 02 92120885 dcook@prosentient.com.au -----Original Message----- Message: 1 Date: Sun, 7 Apr 2013 12:10:30 +0000 From: Marcel de Rooy <M.de.Rooy@rijksmuseum.nl> To: "koha-devel@lists.koha-community.org" <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Koha numbering Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310E20641A@S-MAIL-1B.rijksmuseum.intra> Content-Type: text/plain; charset="us-ascii" Cool discussion :) Here is my thought: If there is no big reason to jump to the next higher number (in this case 3->4) in some period, do it at least every so-much years. That is reason enough.. But please do not jump from 3 to 14 ! Marcel ------------------------------ Message: 2 Date: Sun, 7 Apr 2013 08:45:25 -0400 From: Owen Leonard <oleonard@myacpl.org> To: "koha-devel@lists.koha-community.org" <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Koha numbering Message-ID: <CAO4qe2O9eCbyG8RhMaku7ZiKCJVq7u3qijCKO4_N7oU7=aQwfg@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 I think this is a worthwhile discussion to have, and I'm actually in no hurry (yet) to cut it off. I think there are still aspects which need to be considered. Version numbering is important to different groups for different reasons. For developers, we need version numbering to keep track of where we are in the release cycle and to help us make judgements about how to manage and maintain previous releases. For users the version number gives them an indication about how important it is to upgrade.
But please do not jump from 3 to 14 !
When considering users, I think this is an important consideration. Jumping from 3 to 14 would be really confusing to users, and create expectations about what that version number means. Did we jump 11 version numbers because 3.14 is 11 version numbers better than 3.12? Did we jump 11 version numbers because a pseudo-Koha project has practiced version number inflation? No matter how well we communicate our reasons for switching numbering systems these questions are going to come up. Are we okay with that? I agree with those who worry that incrementing full version numbers like we did point releases before is going to make it more difficult for users to know how important it is to upgrade. As developers we know how much work goes into making 3.10 into 3.12, but users have to weigh a lot of factors when deciding whether and when to upgrade. Self-supporting libraries in particular may not have the resources to upgrade for every version. Will a new numbering scheme make this more difficult for them? All that said, I think it is problematic that we don't have a plan, under the current numbering scheme, to move from 3.x to 4.x. Just to muddy the waters more: What if we came up with a goal (or goals) to set to trigger the flip from 3 to 4, and then implemented the new version scheme from there? That would give the users the satisfaction of seeing a version jump, and give us some lead time to "sell" the new numbering scheme. With apologies to those who want this to be over, -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Hello David As a librairian, I completely agree with you. Changing from 3 to 14 or 16 will raise a many questions, and vendors and Koha staff in libraries will spend a LOT of energy and time on explaining the change. M. Saby David Cook a écrit :
I agree with Marcel and Owen. I don't think it's a good idea to jump from version 3.x to 14.x, and I think version numbering is an important discussion topic, since it affects how Koha is perceived by current and future users.
Having worked in libraries for the past 6-7 years as library staff and not a developer, I can state with a high level of confidence that consistency almost always matters more in libraries than software conventions; it is logically consistent that version 3 be followed by 4. Like Owen said, if that varies, there are going to be questions. While we might debate the merits of different version numbering systems, I don't think we're going to be the ones answering these questions in most cases. They're going to be aimed at trainers, salespeople, and technical staff who might not be developers. With the exception of Nicole, the majority of these people might throw up their hands and say, "I have no idea why it went from 3 to 14. It's weird." In many cases, no questions might be asked. In either case, people might just make negative judgements about the reliability, predictability, and transparency of Koha, especially if the "reason" for changing version numbering systems isn't made explicitly and readily available.
Personally, I think it would make Koha look bad. The more often a Koha front-person says "I don't know" or "that's weird", the worse that person looks and the worse Koha looks.
I think the growing consensus of software users, interface designers, and sellers is "don't make me think". It should be intuitive.
That said, maybe I'm projecting a bit of my own biases. Maybe there would be some confused conversation about why Koha went from 3 to 14, but after the majority started using 14 and upgrading from there, it might not be an issue, because that idea of consistency would be regained.
As for whether or not users and libraries even look at version numbers...I imagine that the vast majority of people interacting directly with Koha never notice them. They don't appear in the OPAC and in the staff client it's tucked away in the system preferences and About page.
The ones caring are likely to be the ones who manage Koha in-house or the people who liaise with support companies. In these cases, maybe it would be easy enough to say, "Oh, the community just decided to change how it numbered each version", but I think this discussion will quickly be lost to time and the average Koha user/developer will have no idea why it changed and as Owen said...I imagine people might wonder if/what they're missing by going from 3.x to 14.x.
For me, I think the most logical end to this discussion is to decide on a goal/trigger to switch to 4.x, and to just continue 3.x until that goal/trigger is reached.
David Cook Systems Librarian Prosentient Systems P/L ABN 31 078 409 168 72/330 Wattle St, Ultimo NSW 2007 tel: 02 92120899 fax: 02 92120885 dcook@prosentient.com.au
-----Original Message-----
Message: 1 Date: Sun, 7 Apr 2013 12:10:30 +0000 From: Marcel de Rooy <M.de.Rooy@rijksmuseum.nl> To: "koha-devel@lists.koha-community.org" <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Koha numbering Message-ID:
<809BE39CD64BFD4EB9036172EBCCFA310E20641A@S-MAIL-1B.rijksmuseum.intra> Content-Type: text/plain; charset="us-ascii"
Cool discussion :) Here is my thought: If there is no big reason to jump to the next higher number (in this case 3->4) in some period, do it at least every so-much years. That is reason enough.. But please do not jump from 3 to 14 !
Marcel ------------------------------
Message: 2 Date: Sun, 7 Apr 2013 08:45:25 -0400 From: Owen Leonard <oleonard@myacpl.org> To: "koha-devel@lists.koha-community.org" <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Koha numbering Message-ID: <CAO4qe2O9eCbyG8RhMaku7ZiKCJVq7u3qijCKO4_N7oU7=aQwfg@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1
I think this is a worthwhile discussion to have, and I'm actually in no hurry (yet) to cut it off. I think there are still aspects which need to be considered.
Version numbering is important to different groups for different reasons. For developers, we need version numbering to keep track of where we are in the release cycle and to help us make judgements about how to manage and maintain previous releases. For users the version number gives them an indication about how important it is to upgrade.
But please do not jump from 3 to 14 !
When considering users, I think this is an important consideration. Jumping from 3 to 14 would be really confusing to users, and create expectations about what that version number means. Did we jump 11 version numbers because 3.14 is 11 version numbers better than 3.12? Did we jump 11 version numbers because a pseudo-Koha project has practiced version number inflation? No matter how well we communicate our reasons for switching numbering systems these questions are going to come up. Are we okay with that?
I agree with those who worry that incrementing full version numbers like we did point releases before is going to make it more difficult for users to know how important it is to upgrade. As developers we know how much work goes into making 3.10 into 3.12, but users have to weigh a lot of factors when deciding whether and when to upgrade. Self-supporting libraries in particular may not have the resources to upgrade for every version. Will a new numbering scheme make this more difficult for them?
All that said, I think it is problematic that we don't have a plan, under the current numbering scheme, to move from 3.x to 4.x.
Just to muddy the waters more: What if we came up with a goal (or goals) to set to trigger the flip from 3 to 4, and then implemented the new version scheme from there? That would give the users the satisfaction of seeing a version jump, and give us some lead time to "sell" the new numbering scheme.
With apologies to those who want this to be over,
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.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/
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de la Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
I'm on the side of moving to Koha 4.0, and then looking into a browser-based means of upgrading the system from there. Firefox, Chrome, Dokuwiki and most mobile apps do not require any kind of additional process to upgrade; you just click the button, and it works (or you look up, and it's updated, if you have automation turned on). The amount of work this would require is significant, and in itself could justify jumping to a new whole number. But having a means whereby libraries can handle the upgrade process on their own timetable, without any need to dip into the commandline. Obviously this would only work for folks following the mainline of Koha, not those working on their own branches, but if you're doing that, you're already responsible for keeping your code up to date and rebased. -Ian On Mon, Apr 8, 2013 at 6:37 AM, Mathieu Saby <mathieu.saby@univ-rennes2.fr>wrote:
** Hello David As a librairian, I completely agree with you. Changing from 3 to 14 or 16 will raise a many questions, and vendors and Koha staff in libraries will spend a LOT of energy and time on explaining the change.
M. Saby
David Cook a écrit :
I agree with Marcel and Owen. I don't think it's a good idea to jump from version 3.x to 14.x, and I think version numbering is an important discussion topic, since it affects how Koha is perceived by current and future users.
Having worked in libraries for the past 6-7 years as library staff and not a developer, I can state with a high level of confidence that consistency almost always matters more in libraries than software conventions; it is logically consistent that version 3 be followed by 4. Like Owen said, if that varies, there are going to be questions. While we might debate the merits of different version numbering systems, I don't think we're going to be the ones answering these questions in most cases. They're going to be aimed at trainers, salespeople, and technical staff who might not be developers. With the exception of Nicole, the majority of these people might throw up their hands and say, "I have no idea why it went from 3 to 14. It's weird." In many cases, no questions might be asked. In either case, people might just make negative judgements about the reliability, predictability, and transparency of Koha, especially if the "reason" for changing version numbering systems isn't made explicitly and readily available.
Personally, I think it would make Koha look bad. The more often a Koha front-person says "I don't know" or "that's weird", the worse that person looks and the worse Koha looks.
I think the growing consensus of software users, interface designers, and sellers is "don't make me think". It should be intuitive.
That said, maybe I'm projecting a bit of my own biases. Maybe there would be some confused conversation about why Koha went from 3 to 14, but after the majority started using 14 and upgrading from there, it might not be an issue, because that idea of consistency would be regained.
As for whether or not users and libraries even look at version numbers...I imagine that the vast majority of people interacting directly with Koha never notice them. They don't appear in the OPAC and in the staff client it's tucked away in the system preferences and About page.
The ones caring are likely to be the ones who manage Koha in-house or the people who liaise with support companies. In these cases, maybe it would be easy enough to say, "Oh, the community just decided to change how it numbered each version", but I think this discussion will quickly be lost to time and the average Koha user/developer will have no idea why it changed and as Owen said...I imagine people might wonder if/what they're missing by going from 3.x to 14.x.
For me, I think the most logical end to this discussion is to decide on a goal/trigger to switch to 4.x, and to just continue 3.x until that goal/trigger is reached.
David Cook Systems Librarian Prosentient Systems P/L ABN 31 078 409 168 72/330 Wattle St, Ultimo NSW 2007 tel: 02 92120899 fax: 02 92120885dcook@prosentient.com.au
-----Original Message-----
Message: 1 Date: Sun, 7 Apr 2013 12:10:30 +0000 From: Marcel de Rooy <M.de.Rooy@rijksmuseum.nl> <M.de.Rooy@rijksmuseum.nl> To: "koha-devel@lists.koha-community.org" <koha-devel@lists.koha-community.org> <koha-devel@lists.koha-community.org> <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Koha numbering Message-ID: <809BE39CD64BFD4EB9036172EBCCFA310E20641A@S-MAIL-1B.rijksmuseum.intra> <809BE39CD64BFD4EB9036172EBCCFA310E20641A@S-MAIL-1B.rijksmuseum.intra> Content-Type: text/plain; charset="us-ascii"
Cool discussion :) Here is my thought: If there is no big reason to jump to the next higher number (in this case 3->4) in some period, do it at least every so-much years. That is reason enough.. But please do not jump from 3 to 14 !
Marcel ------------------------------
Message: 2 Date: Sun, 7 Apr 2013 08:45:25 -0400 From: Owen Leonard <oleonard@myacpl.org> <oleonard@myacpl.org> To: "koha-devel@lists.koha-community.org" <koha-devel@lists.koha-community.org> <koha-devel@lists.koha-community.org> <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Koha numbering Message-ID: <CAO4qe2O9eCbyG8RhMaku7ZiKCJVq7u3qijCKO4_N7oU7=aQwfg@mail.gmail.com> <CAO4qe2O9eCbyG8RhMaku7ZiKCJVq7u3qijCKO4_N7oU7=aQwfg@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1
I think this is a worthwhile discussion to have, and I'm actually in no hurry (yet) to cut it off. I think there are still aspects which need to be considered.
Version numbering is important to different groups for different reasons. For developers, we need version numbering to keep track of where we are in the release cycle and to help us make judgements about how to manage and maintain previous releases. For users the version number gives them an indication about how important it is to upgrade.
But please do not jump from 3 to 14 !
When considering users, I think this is an important consideration. Jumping from 3 to 14 would be really confusing to users, and create expectations about what that version number means. Did we jump 11 version numbers because 3.14 is 11 version numbers better than 3.12? Did we jump 11 version numbers because a pseudo-Koha project has practiced version number inflation? No matter how well we communicate our reasons for switching numbering systems these questions are going to come up. Are we okay with that?
I agree with those who worry that incrementing full version numbers like we did point releases before is going to make it more difficult for users to know how important it is to upgrade. As developers we know how much work goes into making 3.10 into 3.12, but users have to weigh a lot of factors when deciding whether and when to upgrade. Self-supporting libraries in particular may not have the resources to upgrade for every version. Will a new numbering scheme make this more difficult for them?
All that said, I think it is problematic that we don't have a plan, under the current numbering scheme, to move from 3.x to 4.x.
Just to muddy the waters more: What if we came up with a goal (or goals) to set to trigger the flip from 3 to 4, and then implemented the new version scheme from there? That would give the users the satisfaction of seeing a version jump, and give us some lead time to "sell" the new numbering scheme.
With apologies to those who want this to be over,
-- Owen
-- Web Developer Athens County Public Librarieshttp://www.myacpl.org
_______________________________________________ Koha-devel mailing listKoha-devel@lists.koha-community.orghttp://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/
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de la Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
_______________________________________________ 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/
On Mon, Apr 8, 2013 at 1:02 PM, Ian Walls <koha.sekjal@gmail.com> wrote:
I'm on the side of moving to Koha 4.0, and then looking into a browser-based means of upgrading the system from there. Firefox, Chrome, Dokuwiki and most mobile apps do not require any kind of additional process to upgrade; you just click the button, and it works (or you look up, and it's updated, if you have automation turned on).
This could be easily achieved with packages (currently only Debian/Ubuntu supported, more could come).
That's why I proposed changing the package naming schema to the one virtualbox uses. This would allow a user to receive (automatic, like in 'you have pending updates, click install button') bugfix updates until they choose (from a package list for example) they want to move from koha-common-3.12 to koha-common-4.0 (whichever sub-revision number they are in). Regards To+
participants (4)
-
David Cook -
Ian Walls -
Mathieu Saby -
Tomas Cohen Arazi