Re: [Koha-devel] Version numbering, starting a discussion
Paul Poulain <paul.poulain@biblibre.com>
=== DB update numbering === [...] What do you think of this idea ? Why should we keep the previous numbering scheme ? Any other suggestion ?
It doesn't really matter, so go with whatever's easiest to manage, but if you go back to plain numbers, I suggest starting from 4 so that it is still bigger than 3.7.whatever in one sense.
=== Koha version numbering === [...] This question arise because some of our libraries have problem understanding what will be the next version number. It will be 3.8. And the next one ? 3.10 or 4.0, depending on Solr or any other major change being applied. And maybe, in april, Solr will be pushed, in this case it would be called 4.0 (I don't think it will, but it's just for the example) That's quite unclear for external people.
All versioning numbers are hard for some people to understand. At least the current one has the advantage that Linux uses a similar one so there are already some education materials out there.
That's why I was wondering : why not use another, totally new numbering schema.
Because they're all less well-understood than our current one. You wouldn't believe the confusion the YY.MM Ubuntu-ish pattern seems to cause in new users.
There's also another interest with this idea: if we change completly our numbering, we would not seem to be "late" against another software that is currently numbered 4.8 (i've been in Greece recently, for a talk in academic libraries. I saw that there is a big confusion here, and changing the numbering would also help I think).
Screw them. If that's the only reason, let's skip to 5.8 for the next release, or append ".not-a-LibLime-fake" to ours. But do we want to let them interfere with the real project in yet another way? Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha
The way I've seen version numbering is in 4 parts: <major version>.<major release>.<maintenance release>.<DB rev> Major version has at yet been a single digit, but should we get up to major version 9, we'll probably just roll on to 10. It only changes when there are significant reworkings to the internal mechanisms of Koha. Major release is two digits, zero-padded, incrementing by 2 each time, off-set by 1 for development versions. I think the major confusion factor here is the zero-padding. Koha 3.6 and Koha 3.06 are the same thing, but people often confuse 3.06 with 3.0.6, which is a significant difference! Major releases come out every 6 months, now, and I hope that practice will continue. Maintenance releases are also two digit zero-padded values, incrementing by 1 each time. This is done on a strict monthly schedule, and keeps any major release fresh. We rarely get far past a single digit, just given our end-of-life patterns so far, but it can happen. The DB rev is really only for developers or those who follow the master branch. In the absence of the formal maintenance release notes, it gives one an idea exactly what features and bug fixes are included in the software they're running at the moment. This takes form of a 3 digit zero padded value, incrementing by 1 for each change to the database structure or default data. I think this schema works pretty well. The major hiccup I see the zero padding in the major release causing confusion. There is of course confusion introduced by other folks with a similarly-named software package trying to 'one-up' the current Koha version, but that's out of our control, and in my opinion not worth changing our practices over. One possible counter-proposal: instead of just numeric releases, what if we started given them names, as well? Something in a theme agreed upon by the community (Liz Rea and I discussed 'cheeses' as a possible theme, once). About 3 months before the next release, the community solicits ideas for names. Once gathered, we vote. Just an idea :) Cheers, -Ian On Thu, Dec 1, 2011 at 5:40 AM, MJ Ray <mjr@phonecoop.coop> wrote:
Paul Poulain <paul.poulain@biblibre.com>
=== DB update numbering === [...] What do you think of this idea ? Why should we keep the previous numbering scheme ? Any other suggestion ?
It doesn't really matter, so go with whatever's easiest to manage, but if you go back to plain numbers, I suggest starting from 4 so that it is still bigger than 3.7.whatever in one sense.
=== Koha version numbering === [...] This question arise because some of our libraries have problem understanding what will be the next version number. It will be 3.8. And the next one ? 3.10 or 4.0, depending on Solr or any other major change being applied. And maybe, in april, Solr will be pushed, in this case it would be called 4.0 (I don't think it will, but it's just for the example) That's quite unclear for external people.
All versioning numbers are hard for some people to understand. At least the current one has the advantage that Linux uses a similar one so there are already some education materials out there.
That's why I was wondering : why not use another, totally new numbering schema.
Because they're all less well-understood than our current one. You wouldn't believe the confusion the YY.MM Ubuntu-ish pattern seems to cause in new users.
There's also another interest with this idea: if we change completly our numbering, we would not seem to be "late" against another software that is currently numbered 4.8 (i've been in Greece recently, for a talk in academic libraries. I saw that there is a big confusion here, and changing the numbering would also help I think).
Screw them. If that's the only reason, let's skip to 5.8 for the next release, or append ".not-a-LibLime-fake" to ours. But do we want to let them interfere with the real project in yet another way?
Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha _______________________________________________ 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/
-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
=== DB update numbering === [...] What do you think of this idea ? Why should we keep the previous numbering scheme ? Any other suggestion ? It doesn't really matter, so go with whatever's easiest to manage, but if you go back to plain numbers, I suggest starting from 4 so
I think changing our numbering scheme will only cause more confusion than it will help. Perhaps we should have an explanation somewhere in the wiki – but the current numbering is logical and has a lot of important information. -- Katrin From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Ian Walls Sent: Thursday, December 01, 2011 1:46 PM To: MJ Ray Cc: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Version numbering, starting a discussion The way I've seen version numbering is in 4 parts: <major version>.<major release>.<maintenance release>.<DB rev> Major version has at yet been a single digit, but should we get up to major version 9, we'll probably just roll on to 10. It only changes when there are significant reworkings to the internal mechanisms of Koha. Major release is two digits, zero-padded, incrementing by 2 each time, off-set by 1 for development versions. I think the major confusion factor here is the zero-padding. Koha 3.6 and Koha 3.06 are the same thing, but people often confuse 3.06 with 3.0.6, which is a significant difference! Major releases come out every 6 months, now, and I hope that practice will continue. Maintenance releases are also two digit zero-padded values, incrementing by 1 each time. This is done on a strict monthly schedule, and keeps any major release fresh. We rarely get far past a single digit, just given our end-of-life patterns so far, but it can happen. The DB rev is really only for developers or those who follow the master branch. In the absence of the formal maintenance release notes, it gives one an idea exactly what features and bug fixes are included in the software they're running at the moment. This takes form of a 3 digit zero padded value, incrementing by 1 for each change to the database structure or default data. I think this schema works pretty well. The major hiccup I see the zero padding in the major release causing confusion. There is of course confusion introduced by other folks with a similarly-named software package trying to 'one-up' the current Koha version, but that's out of our control, and in my opinion not worth changing our practices over. One possible counter-proposal: instead of just numeric releases, what if we started given them names, as well? Something in a theme agreed upon by the community (Liz Rea and I discussed 'cheeses' as a possible theme, once). About 3 months before the next release, the community solicits ideas for names. Once gathered, we vote. Just an idea :) Cheers, -Ian On Thu, Dec 1, 2011 at 5:40 AM, MJ Ray <mjr@phonecoop.coop> wrote: Paul Poulain <paul.poulain@biblibre.com> that it is still bigger than 3.7.whatever in one sense.
=== Koha version numbering === [...] This question arise because some of our libraries have problem understanding what will be the next version number. It will be 3.8. And the next one ? 3.10 or 4.0, depending on Solr or any other major change being applied. And maybe, in april, Solr will be pushed, in this case it would be called 4.0 (I don't think it will, but it's just for the example) That's quite unclear for external people. All versioning numbers are hard for some people to understand. At least the current one has the advantage that Linux uses a similar one so there are already some education materials out there.
That's why I was wondering : why not use another, totally new numbering schema. Because they're all less well-understood than our current one. You wouldn't believe the confusion the YY.MM Ubuntu-ish pattern seems to cause in new users.
There's also another interest with this idea: if we change completly our numbering, we would not seem to be "late" against another software that is currently numbered 4.8 (i've been in Greece recently, for a talk in academic libraries. I saw that there is a big confusion here, and changing the numbering would also help I think). Screw them. If that's the only reason, let's skip to 5.8 for the next release, or append ".not-a-LibLime-fake" to ours. But do we want to let them interfere with the real project in yet another way?
Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha _______________________________________________ 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/ -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
Katrin failed to mention her excellent counter-proposal to Ian's suggestion of cheese as a theme: cookies and other sweets as the theme. Koha 3.8 Curried coconut oatmeal chocolate chip cookies, etc. Regards, Jared On Thu, Dec 1, 2011 at 10:22 AM, Fischer, Katrin <Katrin.Fischer@bsz-bw.de>wrote:
I think changing our numbering scheme will only cause more confusion than it will help. Perhaps we should have an explanation somewhere in the wiki – but the current numbering is logical and has a lot of important information.
-- Katrin
From: koha-devel-bounces@lists.koha-community.org [mailto: koha-devel-bounces@lists.koha-community.org] On Behalf Of Ian Walls Sent: Thursday, December 01, 2011 1:46 PM To: MJ Ray Cc: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Version numbering, starting a discussion
The way I've seen version numbering is in 4 parts:
<major version>.<major release>.<maintenance release>.<DB rev>
Major version has at yet been a single digit, but should we get up to major version 9, we'll probably just roll on to 10. It only changes when there are significant reworkings to the internal mechanisms of Koha.
Major release is two digits, zero-padded, incrementing by 2 each time, off-set by 1 for development versions. I think the major confusion factor here is the zero-padding. Koha 3.6 and Koha 3.06 are the same thing, but people often confuse 3.06 with 3.0.6, which is a significant difference! Major releases come out every 6 months, now, and I hope that practice will continue.
Maintenance releases are also two digit zero-padded values, incrementing by 1 each time. This is done on a strict monthly schedule, and keeps any major release fresh. We rarely get far past a single digit, just given our end-of-life patterns so far, but it can happen.
The DB rev is really only for developers or those who follow the master branch. In the absence of the formal maintenance release notes, it gives one an idea exactly what features and bug fixes are included in the software they're running at the moment. This takes form of a 3 digit zero padded value, incrementing by 1 for each change to the database structure or default data.
I think this schema works pretty well. The major hiccup I see the zero padding in the major release causing confusion. There is of course confusion introduced by other folks with a similarly-named software package trying to 'one-up' the current Koha version, but that's out of our control, and in my opinion not worth changing our practices over.
One possible counter-proposal: instead of just numeric releases, what if we started given them names, as well? Something in a theme agreed upon by the community (Liz Rea and I discussed 'cheeses' as a possible theme, once). About 3 months before the next release, the community solicits ideas for names. Once gathered, we vote. Just an idea :)
Cheers,
=== DB update numbering === [...] What do you think of this idea ? Why should we keep the previous numbering scheme ? Any other suggestion ? It doesn't really matter, so go with whatever's easiest to manage, but if you go back to plain numbers, I suggest starting from 4 so
-Ian On Thu, Dec 1, 2011 at 5:40 AM, MJ Ray <mjr@phonecoop.coop> wrote: Paul Poulain <paul.poulain@biblibre.com> that it is still bigger than 3.7.whatever in one sense.
=== Koha version numbering === [...] This question arise because some of our libraries have problem understanding what will be the next version number. It will be 3.8. And the next one ? 3.10 or 4.0, depending on Solr or any other major change being applied. And maybe, in april, Solr will be pushed, in this case it would be called 4.0 (I don't think it will, but it's just for the example) That's quite unclear for external people. All versioning numbers are hard for some people to understand. At least the current one has the advantage that Linux uses a similar one so there are already some education materials out there.
That's why I was wondering : why not use another, totally new numbering schema. Because they're all less well-understood than our current one. You wouldn't believe the confusion the YY.MM Ubuntu-ish pattern seems to cause in new users.
There's also another interest with this idea: if we change completly our numbering, we would not seem to be "late" against another software that is currently numbered 4.8 (i've been in Greece recently, for a talk in academic libraries. I saw that there is a big confusion here, and changing the numbering would also help I think). Screw them. If that's the only reason, let's skip to 5.8 for the next release, or append ".not-a-LibLime-fake" to ours. But do we want to let them interfere with the real project in yet another way?
Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha _______________________________________________ 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/
-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal _______________________________________________ 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/
-- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
On 2011-12-2, at 4:31 AM, Jared Camins-Esakov wrote:
Katrin failed to mention her excellent counter-proposal to Ian's suggestion of cheese as a theme: cookies and other sweets as the theme. Koha 3.8 Curried coconut oatmeal chocolate chip cookies, etc.
Regards, Jared
any type of food is a great idea :) (this worked pretty well for the Debian project, and their 'toy story' release names) the 'master' branch would always be called 'ricotta' (a fresh cheese?) ...or some other names? -> http://www.foodsubs.com/Chefresh.html :)
On 2011-12-4, at 1:43 PM, Mason James wrote:
On 2011-12-2, at 4:31 AM, Jared Camins-Esakov wrote:
Katrin failed to mention her excellent counter-proposal to Ian's suggestion of cheese as a theme: cookies and other sweets as the theme. Koha 3.8 Curried coconut oatmeal chocolate chip cookies, etc.
Regards, Jared
any type of food is a great idea :) (this worked pretty well for the Debian project, and their 'toy story' release names)
we could also consider switching to the Debian style?, i have found it quite easy to understand. would it work well for Koha? the Debian project uses both an internal 'linux-kernal' style numbering system (like Koha does already) and people-friendly nick-names too... :) http://wiki.debian.org/DebianReleases http://www.debian.org/releases/ http://www.debian.org/doc/manuals/project-history/ch-releases.en.html
Op 04-12-11 15:04, Mason James schreef:
Katrin failed to mention her excellent counter-proposal to Ian's suggestion of cheese as a theme: cookies and other sweets as the theme. Koha 3.8 Curried coconut oatmeal chocolate chip cookies, etc.
Been done, kinda. I have Android devices running Froyo (an Americanism I guess), Honeycomb (what I think the rest of us call hokey-pokey) and Ice Cream Sandwich (an interesting idea.) Not that I'm averse to it :) I think I prefer it to names such as Onanistic Ocelot[0] ;)
we could also consider switching to the Debian style?, i have found it quite easy to understand. would it work well for Koha?
fwiw (and this won't affect anything to do with Koha numbering), I've been numbering the Debian packages in the Debian style, but as the package detail is in upstream we never get away from '-1' (which is OK) e.g. 3.06.01 is 3.6.1-1. The master builds are along the lines of 3.7-1~git<timestamp>.<git-hash> or something like that. Should I ever need to push a patch in the packaging itself, it would become 3.6.1-2. This matters in debian-land because the source is base on the part before the '-', the stuff after that is debian-release-specific. [0] not the real name. Robin.
Paul, About your first suggestion (the one you didn't want to get buried in the discussion of part 2): It would be feasible to employ a new numbers system just for DB revs (not for releases). DB rev is only really used in master, so the third number (maintenance release) is always "00". What we really need is a multi-headed path through DB revs. We need to be able to trace the DB revision history for both master and stable releases. I'd really like to see an easy way to convert back and forth, so if you're on master, and want to change to stable, you don't have to move the earth. DB revs need to maintain a sequence, as sometimes order of application is important. But if two completely orthogonal things are applied out of sequence, it really doesn't matter. Oh, wait, this is just like in Git! That would lead me back to using a Hash to keep track of the current default DB state, but as it's not just structure, but also data, that gets more complex than possibility really allows. -Ian On Thu, Dec 1, 2011 at 10:22 AM, Fischer, Katrin <Katrin.Fischer@bsz-bw.de>wrote:
I think changing our numbering scheme will only cause more confusion than it will help. Perhaps we should have an explanation somewhere in the wiki – but the current numbering is logical and has a lot of important information.
-- Katrin
From: koha-devel-bounces@lists.koha-community.org [mailto: koha-devel-bounces@lists.koha-community.org] On Behalf Of Ian Walls Sent: Thursday, December 01, 2011 1:46 PM To: MJ Ray Cc: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Version numbering, starting a discussion
The way I've seen version numbering is in 4 parts:
<major version>.<major release>.<maintenance release>.<DB rev>
Major version has at yet been a single digit, but should we get up to major version 9, we'll probably just roll on to 10. It only changes when there are significant reworkings to the internal mechanisms of Koha.
Major release is two digits, zero-padded, incrementing by 2 each time, off-set by 1 for development versions. I think the major confusion factor here is the zero-padding. Koha 3.6 and Koha 3.06 are the same thing, but people often confuse 3.06 with 3.0.6, which is a significant difference! Major releases come out every 6 months, now, and I hope that practice will continue.
Maintenance releases are also two digit zero-padded values, incrementing by 1 each time. This is done on a strict monthly schedule, and keeps any major release fresh. We rarely get far past a single digit, just given our end-of-life patterns so far, but it can happen.
The DB rev is really only for developers or those who follow the master branch. In the absence of the formal maintenance release notes, it gives one an idea exactly what features and bug fixes are included in the software they're running at the moment. This takes form of a 3 digit zero padded value, incrementing by 1 for each change to the database structure or default data.
I think this schema works pretty well. The major hiccup I see the zero padding in the major release causing confusion. There is of course confusion introduced by other folks with a similarly-named software package trying to 'one-up' the current Koha version, but that's out of our control, and in my opinion not worth changing our practices over.
One possible counter-proposal: instead of just numeric releases, what if we started given them names, as well? Something in a theme agreed upon by the community (Liz Rea and I discussed 'cheeses' as a possible theme, once). About 3 months before the next release, the community solicits ideas for names. Once gathered, we vote. Just an idea :)
Cheers,
=== DB update numbering === [...] What do you think of this idea ? Why should we keep the previous numbering scheme ? Any other suggestion ? It doesn't really matter, so go with whatever's easiest to manage, but if you go back to plain numbers, I suggest starting from 4 so
-Ian On Thu, Dec 1, 2011 at 5:40 AM, MJ Ray <mjr@phonecoop.coop> wrote: Paul Poulain <paul.poulain@biblibre.com> that it is still bigger than 3.7.whatever in one sense.
=== Koha version numbering === [...] This question arise because some of our libraries have problem understanding what will be the next version number. It will be 3.8. And the next one ? 3.10 or 4.0, depending on Solr or any other major change being applied. And maybe, in april, Solr will be pushed, in this case it would be called 4.0 (I don't think it will, but it's just for the example) That's quite unclear for external people. All versioning numbers are hard for some people to understand. At least the current one has the advantage that Linux uses a similar one so there are already some education materials out there.
That's why I was wondering : why not use another, totally new numbering schema. Because they're all less well-understood than our current one. You wouldn't believe the confusion the YY.MM Ubuntu-ish pattern seems to cause in new users.
There's also another interest with this idea: if we change completly our numbering, we would not seem to be "late" against another software that is currently numbered 4.8 (i've been in Greece recently, for a talk in academic libraries. I saw that there is a big confusion here, and changing the numbering would also help I think). Screw them. If that's the only reason, let's skip to 5.8 for the next release, or append ".not-a-LibLime-fake" to ours. But do we want to let them interfere with the real project in yet another way?
Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha _______________________________________________ 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/
-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal _______________________________________________ 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/
-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
2011/12/1 Ian Walls <ian.walls@bywatersolutions.com>:
About your first suggestion (the one you didn't want to get buried in the discussion of part 2):
<snip>
DB revs need to maintain a sequence, as sometimes order of application is important. But if two completely orthogonal things are applied out of sequence, it really doesn't matter. Oh, wait, this is just like in Git!
That would lead me back to using a Hash to keep track of the current default DB state, but as it's not just structure, but also data, that gets more complex than possibility really allows.
DB version really becomes meaningless for master/dev use once we allow non-linear and selective application of DB related changes. The only time everyone is likely to be at a common DB version will be at major/maintenance release times. And even then, if someone has opted out of certain DB changes, they may never be "in sync" with everyone else. This leads me to think that the use of hashes is the best option. As Ian mentions, this is common to version control systems which is really what we are talking about here: a DB version control system. /me wonders if we are not re-inventing the wheel here... there's only so many ways to make it round, you know. Kind Regards, Chris
Screw them. If that's the only reason, let's skip to 5.8 for the next release, or append ".not-a-LibLime-fake" to ours. But do we want to let them interfere with the real project in yet another way?
I strongly agree with this. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On 2011-12-2, at 2:31 AM, Owen Leonard wrote:
Screw them. If that's the only reason, let's skip to 5.8 for the next release, or append ".not-a-LibLime-fake" to ours. But do we want to let them interfere with the real project in yet another way?
I strongly agree with this.
yeah, i'm kinda OK with this too... (a bump to 5.8 for the next Koha release)
On Sat, Dec 3, 2011 at 7:34 PM, Mason James <mtj@kohaaloha.com> wrote:
On 2011-12-2, at 2:31 AM, Owen Leonard wrote:
Screw them. If that's the only reason, let's skip to 5.8 for the next release, or append ".not-a-LibLime-fake" to ours. But do we want to let them interfere with the real project in yet another way?
I strongly agree with this.
yeah, i'm kinda OK with this too... (a bump to 5.8 for the next Koha release)
Okay, just to be clear, I was strongly agreeing with the "screw them" part. I interpreted the 5.8 comment as sarcasm. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On 05/12/2011, at 10:30 , Owen Leonard wrote:
On Sat, Dec 3, 2011 at 7:34 PM, Mason James <mtj@kohaaloha.com> wrote:
On 2011-12-2, at 2:31 AM, Owen Leonard wrote:
Screw them. If that's the only reason, let's skip to 5.8 for the next release, or append ".not-a-LibLime-fake" to ours. But do we want to let them interfere with the real project in yet another way?
I strongly agree with this.
yeah, i'm kinda OK with this too... (a bump to 5.8 for the next Koha release)
Okay, just to be clear, I was strongly agreeing with the "screw them" part. I interpreted the 5.8 comment as sarcasm.
-- Owen
A counter thought. Some time back a small but useful browser called Netscape skipped numbers to bring its numbers in line with IE. I always felt that this was pandering to IE, and letting the competition set the schedule. That said, anything but Mozilla's current numbering scheme/philosophy! Even Ubuntu's is more intelligible than that. As for the naming idea. Two ideas: 1. Words with roughly similar meanings to koha. (I suspect there's not enough, but haven't really looked into it) 2. Other famous "gifts" (other than koha!). -ramon.
If this is an offer to sponsor the maintenance of a LTS release (with money or labour), such a version once in a while could be interesting to some. There might be support firms that can offer such a paid service. You can find a list on http://www.koha-community.org/ I don't see why every big Koha release (coming every six months) should be LTS though. Best, Mirko Partha Mukhopadhyay schrieb am 07.12.2011 12:44:44
What about LTS (Long Term Support) release in every six months?
----------------------------------------------------
Dr. Parthasarathi Mukhopadhyay
Lecturer (Sr. Scale)
Department of Library and Information Science
The University of Burdwan (WB)
------------------------------------------
participants (11)
-
Chris Nighswonger -
Fischer, Katrin -
Ian Walls -
Jared Camins-Esakov -
Mason James -
Mirko -
MJ Ray -
Owen Leonard -
Partha Mukhopadhyay -
Ramon Andiñach -
Robin Sheat