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 <[email protected]> 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:* [email protected] [mailto: > [email protected]] *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 > [email protected] > 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 [email protected] 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/
