Release 3.0.0.0

[eborden]

As it currently stands:

• https://www.stackage.org/lts-12.19 is on network-2.6.3.6
• https://www.stackage.org/nightly-2018-11-19 is on network-2.8.0.0

There are a number of packages with upper bounds less than 2.8.0.0 https://packdeps.haskellers.com/reverse/network. Some notable packages are:

• hackage-security
• happstack-server

Is the ecosystem ready for an epoch push?

Is there anything left to get into 3.0.0.0 while we are pushing an epoch?

[kazu-yamamoto]

Yes. The network-bsd package: haskell/network-bsd#1
@hvr is not responding. Probably, he is very busy.

[kazu-yamamoto]

network-bsd has been released.

[kazu-yamamoto]

@eborden @Mistuke I think we are ready to release v3.0.

[eborden]

If @Mistuke is 👍 then I'll cut the release.

[hvr]

Yes sorry, I got indeed side-tracked with the haskell.org migration and stuff; I need to pickup haskell/network-bsd#1 (comment) again; I can allocate time later today (in ~10-12h) to see if there's anything I'd need tweaking in network-3.0 regarding the autoconf/header business to help network-bsd if you can wait a couple more hours...

[kazu-yamamoto]

We can wait!

[Mistuke]

Yup I have no objections. Just FYI, I'm finishing up the final bits of a new I/O manager for Windows in GHC. Which will require completely new code in network using the native async APIs. I'll create a ticket soon to start discussing how this should all look.

[eborden]

@Mistuke Oh baby, that sounds like a whopper. Will that require any API changes? That will force us to bump the lower bound of base and drop support for many GHC versions. We should probably open an issue specifically for discussing that.

[Mistuke]

@eborden Yeah, it's years of work, the GHC patch itself clocks in at around 7k lines of code atm, without comments.. lol. On the bright side, it will fix almost all of the warts/quirks on Windows.

I haven't thought about the API in network yet, my hope is that since Winsock was originally based on BSD sockets anyway the native interface is close enough to maintain the same interface for most things. At least for IOCP, Still need to look into RIO support.

Yes I'll create a new ticket to discuss it through before I start any work on it. In terms of base GHC will (at least for a period) support both I/O managers and provides hooks and helpers to switch between the two for library code (the same helpers base uses). The new I/O manager won't be the default for a while, not the least until core libraries catch up.

My intention for this is to use Win32 to abstract that functionality, such that you will have to bump the minimum version of Win32 but not base. Win32 still maintains backwards compatibility back to GHC 7.6 which is a reasonably ways back.

[hvr]

@eborden

That will force us to bump the lower bound of base and drop support for many GHC versions.

...but only if os(windows), no?

[kazu-yamamoto]

I think we should release version 3.0.0.0 in the next week anyway.

[kazu-yamamoto]

@Mistuke Sound exciting!

What does RIO mean?

[kazu-yamamoto]

@winterland1989 @Mistuke I would like to know whether of not Mio, libuv based IO manager and the new I/O manager for Windows can coexist if we create a proper layer to GHC.

[winterland1989]

I'm not sure if IOCP based IO manager can be easily combined with current event-based interface, namely threadWaitRead/threadWaitWrite. I gave a talk on this on Haskell symposium 2018 and i don't think it's an easy job, but maybe @Mistuke can tell more on this.

On the other hand libuv based IO manager is a one-stop solution since libuv already take care of system call encapsulation, it's not only an IO manager but also a substitution to all the system packages, e.g. network, directory, etc. It should be able to coexist with whatever IO solution base provides, as a third-package.

[eborden]

Hey y'all I don't want this conversation in this issue to get too off target. I'd like to move this discussion over here: #364

[hvr]

@kazu-yamamoto @eborden why is network suddenly become a build-type: Custom package? This is going to cause some headaches in the long-run (as well as cause unnecessary penalties for everyone building network as it forces a slower codepath with potential recompilations of lib:Cabal etc, quite some poential for bugs as the combination of build-type:Custom with autoconf-scripts is a tricky combination which hasn't gotten much testing and I expect corner cases of breakage, as well as implicitly limit the oldest GHC we can support) :-/

[kazu-yamamoto]

@hvr It's for cabal-doctest (on CIs)

[hvr]

@kazu-yamamoto there's ways to run doctest without making everyone else pay for it :-)

Btw, I've noticed a problem with network-3: it doesn't seem to install HsNetworkConfig.h anymore (network-2.8 did, so this is a regression) and thus breaks the HsNet.h/HsNetDef.h headers for consumers. I'm looking into this.

update: This is btw what I'd need in network-3.0.0.0 for network-bsd https://github.com/haskell/network/tree/wip/fix-hsnetworkregression

[kazu-yamamoto]

@hvr your branch has been merged.

[kazu-yamamoto]

there's ways to run doctest without making everyone else pay for it :-)

@hvr Would you explain how to know the build directory on cabal new-configure corresponding to dist/build on cabal configure.

[hvr]

@kazu-yamamoto that's indeed a trickier thing to do, but doable in principle; however, there's a simpler approach imho, which I've filed as #365; is this something that would work for you?

[kazu-yamamoto]

I think it's high time to release network 3.0.0.0!

[eborden]

I went to upload a package candidate. Is there a reason we dropped Setup.hs?

[eborden]

Looks like some info in here: #365

They're only needed for compliant source-tarballs -- and cabal sdist will include a default Setup.hs automatically;

I'm using cabal v2-sdist which does not seem to be doing this. I'm going to include one myself and open a bug against v2-sdist.

[eborden]

Candidate is up here:

http://hackage.haskell.org/package/network-3.0.0.0/candidate

Changelog is currently:

## Version 3.0.0.0

* Breaking change: the Network and Network.BSD are removed.
* Breaking change: the signatures are changed:
    old fdSocket :: Socket -> CInt
    new fdSocket :: Socket -> IO CInt

    old mkSocket :: CInt -> Family -> SocketType -> ProtocolNumber -> SocketStatus -> IO Socket
    new mkSocket :: CInt Socket
* Breaking change: the deprecated APIs are removed: send, sendTo, recv, recvFrom, recvLen, htonl, ntohl, inet_addr, int_ntoa, bindSocket, sClose, SocketStatus, isConnected, isBound, isListening, isReadable, isWritable, sIsConnected, sIsBound, sIsListening, sIsReadable, sIsWritable, aNY_PORT, iNADDR_ANY, iN6ADDR_ANY, sOMAXCONN, sOL_SOCKET, sCM_RIGHTS, packSocketType, getPeerCred.
* Breaking chage: SockAddrCan is removed from SockAddr.
* Socket addresses are extendable with Network.Socket.Address.
* "socket" is now asynchronous-exception-safe.
  [#336](https://github.com/haskell/network/pull/336)
* "recvFrom" returns (0, addr) instead of throwing an error on EOF.
  [#360](https://github.com/haskell/network/pull/360)
* All APIs are available on any platforms.
* Build system is simplified.
* Bug fixes.

@kazu-yamamoto @Mistuke, everything look good to you?

[eborden]

Issue opened for cabal.

haskell/cabal#5849

[Mistuke]

Changelog should probably mention that Network.BSD was moved to its own package. Otherwise looks good to me. Thanks @eborden!

[kazu-yamamoto]

I have created the setup branch to fix Setup.hs issue and to allow HSPEC 2.7: https://github.com/kazu-yamamoto/network/branches

Waiting for CIs.

[kazu-yamamoto]

The branch has been merged.
@Mistuke Changelog has been updated.

@eborden I think we are ready.

[eborden]

Version 3.0.0.0 is out.
http://hackage.haskell.org/package/network-3.0.0.0

Cafe message sent:

Announcing the release of network 3.0.0.0
http://hackage.haskell.org/package/network-3.0.0.0

Version 3.0.0.0 of network is less platform dependent, easier to build, easier to use correctly (yay no more String api), more extensible, and all around safer. Kazu Yamamoto and Tamar Christina deserve a special shout out, they put an exceptional amount of thought and work into this version and it really shows. Thanks to network's contributors for kicking the tires and continuing to keep quality high.

Version 3.0.0.0

• Breaking change: the Network and Network.BSD are removed.
  Network.BSD is provided a new package: network-bsd.
• Breaking change: the signatures are changed:

old fdSocket :: Socket -> CInt
new fdSocket :: Socket -> IO CInt

old mkSocket :: CInt -> Family -> SocketType -> ProtocolNumber -> SocketStatus -> IO Socket
new mkSocket :: CInt Socket

• Breaking change: the deprecated APIs are removed: send, sendTo, recv, recvFrom, recvLen, htonl, ntohl, inet_addr, int_ntoa, bindSocket, sClose, SocketStatus, isConnected, isBound, isListening, isReadable, isWritable, sIsConnected, sIsBound, sIsListening, sIsReadable, sIsWritable, aNY_PORT, iNADDR_ANY, iN6ADDR_ANY, sOMAXCONN, sOL_SOCKET, sCM_RIGHTS, packSocketType, getPeerCred.
• Breaking chage: SockAddrCan is removed from SockAddr.
• Socket addresses are extendable with Network.Socket.Address.
• "socket" is now asynchronous-exception-safe.
  #336
• "recvFrom" returns (0, addr) instead of throwing an error on EOF.
  #360
• All APIs are available on any platforms.
• Build system is simplified.
• Bug fixes.

[eborden]

Tag is up as well https://github.com/haskell/network/releases/tag/v3.0.0.0

[hvr]

Great! I'll take care of a matching network-bsd release rsn

[eborden]

Thanks @hvr!

[shmish111]

What will it take to get this onto stackage?

[kazu-yamamoto]

I guess you should ask stackage guys, not here.

[shmish111]

I just found commercialhaskell/stackage#4528 so it looks like this will be sorted this month.