For time-1.5, I'm removing the dependency on old-locale, and including that code directly in Data.Time.Format. The package will also include its own deprecated System.Locale. I expect this to be a popular, decade-overdue move, but if you have some complaint, let me know before I release it. Repository is at https://github.com/haskell/time -- Ashley Yakeley
* Ashley Yakeley
For time-1.5, I'm removing the dependency on old-locale, and including that code directly in Data.Time.Format. The package will also include its own deprecated System.Locale.
I expect this to be a popular, decade-overdue move, but if you have some complaint, let me know before I release it.
Repository is at https://github.com/haskell/time
Great! Would it be possible to re-export time locale stuff from Data.Time.Format, too? (And, transitively, from Data.Time.) Roman
On 2014-08-24 01:47, Roman Cheplyaka wrote:
Would it be possible to re-export time locale stuff from Data.Time.Format, too? (And, transitively, from Data.Time.)
The locale stuff is in Data.Time.Format.Locale, which is hidden. It is exported by Data.Time.Format and by System.Locale (marked deprecated). -- Ashley
On Sun, Aug 24, 2014 at 8:18 AM, Ashley Yakeley
For time-1.5, I'm removing the dependency on old-locale, and including that code directly in Data.Time.Format. The package will also include its own deprecated System.Locale.
I expect this to be a popular, decade-overdue move, but if you have some complaint, let me know before I release it.
Repository is at https://github.com/haskell/time
I'm +1 on the general concept of moving away from old-locale, so I'm happy this is happening, thanks Ashley! One concern I have is that, with this move, we'll now have two core packages both exporting a System.Locale module, which can cause a bit of mayhem for users. Users with cabal files can simply avoid including `old-locale`, but that would mean that it would be difficult to maintain backwards compatibility with time 1.4. Another possibility would be encouraging users to use cabal flags for conditional compilation. What about instead of providing System.Locale, renaming it to something like System.OldLocale. And then also releasing a new version in the time 1.4 series that re-exports old-locale's System.Locale module under the name System.OldLocale as well. I think that might make it a bit easier to have an upgrade path: users would be able to import System.OldLocale regardless of using time 1.4 or 1.5. I also agree with Roman's idea of exporting the locale stuff (or at the very least defaultTimeLocale) from Data.Time.Format, which might be an even easier way to have a migration path. I think there's probably a better proposal to the one I'm making here, so consider it a strawman to start a conversation. I just want to avoid a situation where new users go into GHCi, type `import System.Locale`, and get very confused. Michael
On 2014-08-24 03:44, Michael Snoyman wrote:
One concern I have is that, with this move, we'll now have two core packages both exporting a System.Locale module, which can cause a bit of mayhem for users.
Fair enough, I can remove it if it will cause more problems than it solves.
What about instead of providing System.Locale, renaming it to something like System.OldLocale. And then also releasing a new version in the time 1.4 series that re-exports old-locale's System.Locale module under the name System.OldLocale as well.
There's no point introducing another module name. If we go this road, it would look like this: time-1.5:Data.Time.Format re-exports old-locale:System.Locale time-1.6:Data.Time.Format exports its own locale stuff I'm just not sure the intervening step is necessary. -- Ashley
On Sun, Aug 24, 2014 at 1:56 PM, Ashley Yakeley
On 2014-08-24 03:44, Michael Snoyman wrote:
One concern I have is that, with this move, we'll now have two core
packages both exporting a System.Locale module, which can cause a bit of mayhem for users.
Fair enough, I can remove it if it will cause more problems than it solves.
What about instead of providing System.Locale, renaming it to something
like System.OldLocale. And then also releasing a new version in the time 1.4 series that re-exports old-locale's System.Locale module under the name System.OldLocale as well.
There's no point introducing another module name. If we go this road, it would look like this:
time-1.5:Data.Time.Format re-exports old-locale:System.Locale time-1.6:Data.Time.Format exports its own locale stuff
I'm just not sure the intervening step is necessary.
I was thinking of shifting it up one version: time-1.4.3 would re-export old-locale's code, and time-1.5 would continue as you have it now. This way, users wanting to stick with time-1.4 for some reason would just need to bump their lower bound to 1.4.3. I'm honestly not sure if this is worth it though; the most likely users to run into this problem are people on Haskell Platform, and those users won't have the option of upgrading to a time point release anyway. Michael
participants (3)
-
Ashley Yakeley -
Michael Snoyman -
Roman Cheplyaka