https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23030
David Cook <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from David Cook <[email protected]> --- This is an interesting one... Working as a vendor, I'm not going to want every software release to do a database update. Sometimes a software release might include just a 1 character change after all. Ideally, an update of a live system should be run as fast as possible to minimize any downtime. But... perhaps C4::Installer::update() or 4::Installer::SetVersion() could record a date of update in the database when it has a database update to do anyway. -- Another idea is rather than an install/upgrade date/timestamp we could do a "build" date/timestamp. With this idea, every software update would be captured, so long as it was made via the full software deployment process and not as a hot fix. That's something I've been pondering for a while. As part of the Koha build, a file could be generated that includes a timestamp and possibly other build information. (The trick here is that it would be a system-wide file and not an instance-specific file, so we'd either need to add a line to koha-conf.xml which isn't great from an upgrade point of view, or we'd need to come up with an alternative idea for how to find the file. For example, we could use a Perl module to find the /usr/share/koha/lib and then work backwards from there. This is a method used by some web frameworks, so there is some precedent there.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
