Version 0.7/0.7a - Githubissues

djspiewak commented 9 years ago

I'd like to request that we start the process to release version 0.7 once we have a resolution to #330 vs #318. There are several other important fixes which have landed since 0.6, and it would be nice to get them out. The only other thing I can think of that I want to get into this release is a minor version bump in our scodec/scodec dependency and the appropriate change to io.toInputStream. Basically, @mpilquist exposed a function in ByteVector that will make the inner buffering much faster in certain cases. I'll have that taken care of and PRed this weekend (update: PR'd in #332).

pchlupacek commented 9 years ago

@djspiewak cool. can we put a list what needs to be done before release? I just created milestone, perhaps we can add just issues to it?

djspiewak commented 9 years ago

Update: moved release notes draft to a wiki page.

fthomas commented 9 years ago

I can't edit your message, but #298 should also be mentioned under Bug Fixes:

Fixed time.duration to obtain a new reference time on every Task evaluation

djspiewak commented 9 years ago

I can't edit your message, but #298 should also be mentioned

Updated. Also, should I perhaps stick the release notes in a Gist or a wiki page? I didn't realize that only collaborators could edit messages.

fthomas commented 9 years ago

The release notes of past releases are in the scalaz-stream wiki, so its reasonable to also put them there.

alissapajer commented 9 years ago

The merge of master into master-a isn't clean. Are there any objections to just creating a new master-a based off master and then force-pushing master-a?

djspiewak commented 9 years ago

Ok, looks like we're good to go for 0.7! Attention, @pchiusano. Your party would like to meet you at the front desk.

alissapajer commented 9 years ago

master-a is now updated!

pchiusano commented 9 years ago

Sweet. Question - do we want to try to do the release on sonatype? I can also just do a bintray release for now and we can use the same tag / series to do a release on sonatype, in case there is any red tape with that.

A while ago, @fthomas asked me about putting together a CONTRIBUTORS file. I'd like to do that as part of this release. I don't really want to be the one in charge of deciding how to describe everyone's contributions, but was thinking: names listed alphabetically by last name, and each contributor maintains their own one-line description of what they've worked on.

fthomas commented 9 years ago

@pchiusano are you still planning to rename the project? From what @djspiewak wrote in https://github.com/scalaz/scalaz-stream/issues/258#issuecomment-77590139 it seems to be easier to rename the project before releasing to Maven Central.

pchiusano commented 9 years ago

@fthomas Yeah, though not for 0.7. Also, we still need to come up with a good replacement name. :)

pchiusano commented 9 years ago

Also, I am currently on childcare duty so I prob won't be able to cut release until Monday at earliest. :)

alissapajer commented 9 years ago

@pchiusano great! We would use a public release as soon as it's available (we're already working off of locally-published jars :) ) so if a bintray release is easier, I'd say we should just go for that first. If/when there's demand for a sonatype release, then that could come second.

I have no preference for the presence of a CONTRIBUTORS file or not, but if there is one, I'd say it makes sense for each developer to just submit a PR adding themself and a tagline to the file.

pchiusano commented 9 years ago

Created here: https://github.com/scalaz/scalaz-stream/blob/master/CONTRIBUTORS.markdown

No need to do PRs if you already have commit access. In fact, if you are feeling really lazy, you can just edit the markdown directly from the GitHub site. :)

On Fri, Mar 20, 2015 at 12:36 PM Alissa Pajer notifications@github.com wrote:

@pchiusano https://github.com/pchiusano great! We would use a public release as soon as it's available (we're already working off of locally-published jars :) ) so if a bintray release is easier, I'd say we should just go for that first. If/when there's demand for a sonatype release, then that could come second.

I have no preference for the presence of a CONTRIBUTORS file or not, but if there is one, I'd say it makes sense for each developer to just submit a PR adding themself and a tagline to the file.

— Reply to this email directly or view it on GitHub https://github.com/scalaz/scalaz-stream/issues/331#issuecomment-84063739 .

pchiusano commented 9 years ago

Okay, I did the release on bintrary, I'd like to get the release notes cleaned up before announcing, though. Please hold off on any announcements for the time being.

alissapajer commented 9 years ago

Awesome :)

pchiusano commented 9 years ago

Okay, @djspiewak @alissapajer @pchlupacek @fthomas I cleaned up the release notes page a bit. Could you all take a look through and see if there is anything missing?

https://github.com/scalaz/scalaz-stream/wiki/0.7

Also, @djspiewak can you do a better job of characterizing the issues with tcp? And if there are issues, can we get some failing tests added? If you don't have time to do that, I'd maybe just say: "The new tcp module should still be considered alpha quality. We've noticed a number of issues with it that we are still tracking down. If you'd like to help make the module production quality, please get in touch."

pchiusano commented 9 years ago

Also, @djspiewak on my edits, I tried to succinctly characterize the situations in which the finalization semantics changes is relevant to users (basically resource allocation plus use of nondeterministic functions). That way the person reading can decide to what extent they need to really dig in (like scodec-stream's usage of scalaz-stream doesn't care about any of that). I also moved that long technical discussion to the end, so people can quickly scan the rest of the items.

djspiewak commented 9 years ago

@pchiusano On the issues with tcp, I did file a long issue which contains (as I recall?) three sub issues. I would break things down into two significant categories:

The type signatures are wrong, and satisfying those signatures internally results in incorrect (or at the very least, unexpected) semantics. tcp.server taking a concurrency bound and then still returning a nested process is the best example of this, especially if an application wants to do something useful with the values produced by the connection handlers.
The existing tests mostly don't work, and appear to have only worked in the past due to thread scheduling vagaries (e.g. the fact that leading Suspend blocks used to be run nonconcurrently). You can take a look at the changes I made just to get the bug/step branch running. In a sense, you can actually treat the existing tests as "failing tests", since I directly disabled functionality in the tests in order to make them work.

Anyway, the issue I filed has a lot more details. I'm fine with just saying "should be considered alpha quality". I just wanted to get a warning in the release notes, since people might be looking at using it in its current state, which I don't believe would be the best idea. I do plan on working on the tcp stuff in this next release cycle. It's a little lower on my priority list than optimized chunk processing and onComplete soundness, but it is on my list.

On a completely separate note, I'm pretty sure that the close0 hang in the NIO2 support on Mac is actually a bug in Darwin, based on the effect it has on the process image and the way that the JDK implements that function. So that sort of sucks, because it means our odds of fixing it are pretty low.

alissapajer commented 9 years ago

@pchiusano Just read through the release notes and added a couple things. Looks good to me.

fthomas commented 9 years ago

I added the Process1Syntax.contramap and the typeclass instances for Process1. LGTM

djspiewak commented 9 years ago

@pchiusano Are we green for tweeting/etc about 0.7?

pchiusano commented 9 years ago

Standby, I will send an email to the scalaz list which you can link to if you like.

On Tue, Mar 24, 2015 at 1:36 PM Daniel Spiewak notifications@github.com wrote:

@pchiusano https://github.com/pchiusano Are we green for tweeting/etc about 0.7?

— Reply to this email directly or view it on GitHub https://github.com/scalaz/scalaz-stream/issues/331#issuecomment-85612119 .

pchiusano commented 9 years ago

Okay, fire away: https://groups.google.com/forum/#!topic/scalaz/sKMmvVChK08

On Tue, Mar 24, 2015 at 3:14 PM Paul Chiusano paul.chiusano@gmail.com wrote:

Standby, I will send an email to the scalaz list which you can link to if you like.

On Tue, Mar 24, 2015 at 1:36 PM Daniel Spiewak notifications@github.com wrote:

@pchiusano https://github.com/pchiusano Are we green for tweeting/etc about 0.7?

— Reply to this email directly or view it on GitHub https://github.com/scalaz/scalaz-stream/issues/331#issuecomment-85612119 .

djspiewak commented 9 years ago

0.7/0.7a is released and we're all shouting about it. I'm going to close this issue.

Thanks so much for cutting the release, Paul! I know I'm super-psyched for the changes.

fthomas commented 9 years ago

Also, we still need to come up with a good replacement name.

Can we do something about this? Like opening an issue where people can post their suggestions? Or anything else? I'd love to see scalaz-stream getting a new name sooner rather than later.

typelevel / fs2

Version 0.7/0.7a #331