mellon-core 0.7.0.1 → 0.7.0.3
raw patch · 3 files changed
+15/−8 lines, 3 filesPVP ok
version bump matches the API change (PVP)
API changes (from Hackage documentation)
Files
- README.md +1/−1
- changelog.md +8/−0
- mellon-core.cabal +6/−7
README.md view
@@ -26,4 +26,4 @@ of higher-level packages which use the base `mellon-core` package (e.g., `mellon-web`). -[](https://travis-ci.org/dhess/mellon)+[](https://travis-ci.org/dhess/mellon)
changelog.md view
@@ -1,3 +1,11 @@+## 0.7.0.3 (2016-09-23)++- No changes, version bump only.++## 0.7.0.2 (2016-09-23)++- No changes, version bump only.+ ## 0.7.0.1 (2016-06-13) - Packaging fixes only.
mellon-core.cabal view
@@ -1,5 +1,5 @@ Name: mellon-core-Version: 0.7.0.1+Version: 0.7.0.3 Cabal-Version: >= 1.10 Build-Type: Simple Author: Drew Hess <src@drewhess.com>@@ -46,15 +46,15 @@ @mellon-core@ uses UTC dates for unlock expiration, rather than a time delta or a monotonic clock. You might disagree with this decision based on the common wisdom that it's a bad idea to use- "wall clock time" (of which UTC is one flavor) for timers. In+ \"wall clock time\" (of which UTC is one flavor) for timers. In general, the common wisdom is correct. Wall clocks have lots of problems: they may not be accurate, they may disagree from one- system to the next, they may "jump around" if the system is running+ system to the next, they may \"jump around\" if the system is running a time daemon such as NTP, and they occasionally do something unexpected like adding a leap second. . If your timers must be high-precision (i.e., this timer must run for- exactly /n/ microseconds, for some definition of "exactly"), then+ exactly /n/ microseconds, for some definition of \"exactly\"), then there's no argument: using a wall clock is a bad idea. However, as @mellon-core@ is designed for use with physical access devices, which themselves are typically designed for human factors, accuracy@@ -74,7 +74,7 @@ in networked environments, where network problems may appreciably delay the delivery of commands from client to server. If a user wants to unlock a device for 7 seconds, does that mean 7 seconds- from the clock time @T@ when the user presses "send," or does it+ from the clock time @T@ when the user presses \"send,\" or does it mean 7 seconds from opening to close, regardless of when the server receives the command? Without a common reference, there is no way for the user to communicate her intent.@@ -204,5 +204,4 @@ Source-Repository this Type: git Location: git://github.com/dhess/mellon.git- Branch: v0.7.0- Tag: v0.7.0.1a+ Tag: v0.7.0.3