We still need to fix our packaging schema in which people are forced to jump into .0 releases because of our repository naming schema. I propose we step forward and create "3.18", "3.20" and so on, instead of just "stable", "oldstable", etc. This way no one will be forced to jump into another major release. "stable" "oldstable" and "testing" might still be usable as they are now, nothing prevents a .deb package from populating more than one slot. Or even of symbolic links... Some of you expressed your concerns about "people indefinitely using obsolete/insecure releases". I propose that once a release goes "unmaintained" [1] a "last" release/package adding a red-notorious warning message on the intranet footer is pushed stating that the release is no longer maintained and provinding a link for upgrade instructions. I hope we can fix this once and for all soon. [1] unmaintained = it has no release maintainer on some "Roles for XX" vote. -- Tomás Cohen Arazi Prosecretaría de Informática Universidad Nacional de Córdoba ✆ +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F
Hi Tomás, On Wed, Feb 25, 2015 at 12:25 AM, Tomas Cohen Arazi <tomascohen@gmail.com> wrote:
I propose we step forward and create "3.18", "3.20" and so on, instead of just "stable", "oldstable", etc. This way no one will be forced to jump into another major release.
+1 I've faced support calls from people who have "accidentally" managed to upgrade their installed version, after a new version had been released and moved into stable. so, this certainly makes sense.
Some of you expressed your concerns about "people indefinitely using obsolete/insecure releases". I propose that once a release goes "unmaintained" [1] a "last" release/package adding a red-notorious warning message on the intranet footer is pushed stating that the release is no longer maintained and provinding a link for upgrade instructions.
It's a good idea. But IMHO people who get stuck into older releases are unlikely to benefit.
From my experience, people usually install either the latest version of the 'oldstable' OR they go for the "stable" and if they do install from stable, they will usually install the X.X.01 or higher of the "stable" version in order to benefit from the bugfixes etc after release of a new version.
Now the ones that have been updating would keep on updating and thus once a new release moves in the "stable" would move into that as a general maintenance task. But the ones that do not / can not upgrade, they are likely to miss the last "flagged" release. Instead how about a "Check for upgrade" link in the intranet? Just my 2 cents :) cheers -- Indranil Das Gupta Phone : +91-98300-20971 Blog : http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org
I’ve been wondering a bit about the best way to do this as well. I recently put together two Koha boxes using the Debian packages, and I’m not sure how they will manage when it comes to versions. On one hand, they might not have enough technical knowledge, and that will mean they might “accidentally” upgrade. On the other hand, they might have enough technical knowledge, so they might pin the package or manage their version upgrades some other way. I’m not sure how much we can predict and compensate for the behaviour and knowledge of people installing Koha. In the case of the boxes I put together, they don’t have enough technical knowledge. But that lack of knowledge might indicate that they need to employ someone that does have that knowledge to look after their Koha box. I don’t know :S. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Tomas Cohen Arazi Sent: Wednesday, 25 February 2015 5:56 AM To: koha-devel Subject: [Koha-devel] Upgrade path for packages We still need to fix our packaging schema in which people are forced to jump into .0 releases because of our repository naming schema. I propose we step forward and create "3.18", "3.20" and so on, instead of just "stable", "oldstable", etc. This way no one will be forced to jump into another major release. "stable" "oldstable" and "testing" might still be usable as they are now, nothing prevents a .deb package from populating more than one slot. Or even of symbolic links... Some of you expressed your concerns about "people indefinitely using obsolete/insecure releases". I propose that once a release goes "unmaintained" [1] a "last" release/package adding a red-notorious warning message on the intranet footer is pushed stating that the release is no longer maintained and provinding a link for upgrade instructions. I hope we can fix this once and for all soon. [1] unmaintained = it has no release maintainer on some "Roles for XX" vote. -- Tomás Cohen Arazi Prosecretaría de Informática Universidad Nacional de Córdoba ✆ +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F
Hello, Could we do something like MySQL packages in Debian? That is, having koha-3.18, koha-3.20 packages track respective versions and koha-stable, koha-beta that depends on the package of the latest version? -pongtawat On Wed, Feb 25, 2015 at 11:20 AM, David Cook <dcook@prosentient.com.au> wrote:
I’ve been wondering a bit about the best way to do this as well.
I recently put together two Koha boxes using the Debian packages, and I’m not sure how they will manage when it comes to versions.
On one hand, they might not have enough technical knowledge, and that will mean they might “accidentally” upgrade.
On the other hand, they might have enough technical knowledge, so they might pin the package or manage their version upgrades some other way.
I’m not sure how much we can predict and compensate for the behaviour and knowledge of people installing Koha. In the case of the boxes I put together, they don’t have enough technical knowledge. But that lack of knowledge might indicate that they need to employ someone that does have that knowledge to look after their Koha box.
I don’t know :S.
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St, Ultimo, NSW 2007
*From:* koha-devel-bounces@lists.koha-community.org [mailto: koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Tomas Cohen Arazi *Sent:* Wednesday, 25 February 2015 5:56 AM *To:* koha-devel *Subject:* [Koha-devel] Upgrade path for packages
We still need to fix our packaging schema in which people are forced to jump into .0 releases because of our repository naming schema.
I propose we step forward and create "3.18", "3.20" and so on, instead of just "stable", "oldstable", etc. This way no one will be forced to jump into another major release.
"stable" "oldstable" and "testing" might still be usable as they are now, nothing prevents a .deb package from populating more than one slot. Or even of symbolic links...
Some of you expressed your concerns about "people indefinitely using obsolete/insecure releases". I propose that once a release goes "unmaintained" [1] a "last" release/package adding a red-notorious warning message on the intranet footer is pushed stating that the release is no longer maintained and provinding a link for upgrade instructions.
I hope we can fix this once and for all soon.
[1] unmaintained = it has no release maintainer on some "Roles for XX" vote.
--
Tomás Cohen Arazi
Prosecretaría de Informática
Universidad Nacional de Córdoba
✆ +54 351 5353750 ext 13168
GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F
_______________________________________________ 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/
Tomas Cohen Arazi schreef op di 24-02-2015 om 15:55 [-0300]:
We still need to fix our packaging schema in which people are forced to jump into .0 releases because of our repository naming schema.
I propose we step forward and create "3.18", "3.20" and so on, instead of just "stable", "oldstable", etc. This way no one will be forced to jump into another major release.
What would make this easier is some form of automation. I hope, when I get the chance, to write some scripts that make the package building a bit easier, perhaps using a VM to do it or something.
"stable" "oldstable" and "testing" might still be usable as they are now, nothing prevents a .deb package from populating more than one slot. Or even of symbolic links...
The pocket has to go into the changelog, so it's not totally simple. However, it would be feasible with symlinks, which is how I did the more recent change. This leads me on to something I plan to do that will probably make this all a bit easier: separating the debian/ directory from the main repo. Probably into a totally separate repo. This may seem weird, but it has some advantages, such as being able to use the Debian pkg-perl tools to manage things, and keeping it more in line with how perl libraries and applications are done in general. I'm not sure yet if it'll be a partial or total split (i.e. should debian/scripts and debian/templates remain in the main Koha repo, maybe cron and init stuff too - thereby having just the strictly packaging things in the separate repo.) However, it'll make making slightly different twists on packages a whole lot easier, for example where there's just a changelog change, or dependency issues to handle a difference between ubuntu and debian, or something like that. It would also make easier automation and having more distinct pockets. Anyway, some time soon I hope to do some planning on this, rather than just dumping thoughts into an email. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
participants (5)
-
David Cook -
Indranil Das Gupta -
Pongtawat Chippimolchai -
Robin Sheat -
Tomas Cohen Arazi