Fs2: RFC on release roadmap

[mpilquist]

Hi all,

Paul and I have been making a ton of progress on the new interpreter and API simplifications in the topic/fast branch. We've got a lot of documentation to write and some bugs to fix in async resource allocation. We've started a migration guide if you want a preview: https://github.com/functional-streams-for-scala/fs2/blob/db221ff367ce14a9442bbf954523aac83b9dd490/docs/migration-guide-1.0.md.

Yesterday there was a discussion in Gitter about release numbering -- the result is that topic/fast won't be called 1.0 initially. Rather, it will be a 0.next release so we can get mileage on the API before declaring it 1.0.

Timing wise, we hope to have the first milestone of topic/fast available in the next few weeks, with a final release in late summer or early fall.

As of right this moment, the series/0.10 branch is the 0.9 design but with cats and cats-effect replacing the old fs2.util type classes and Task.

We could go with either of these release plans:

• Plan 1: Release 0.10 now and then release topic/fast as 0.11. 0.10 ends up as the 0.9 design with cats + cats-effect and 0.11 is cats + cats-effect + topic/fast.
• Plan 2: Release 0.10 in late summer with milestones throughout the summer, including topic/fast. 0.10 ends up as cats + cats-effect + topic/fast.

Plan 1 is the most flexible, but it's an increased maintenance burden -- fixes would need to be applied to 0.9, 0.10, and 0.11 for quite a while. It also forces downstream projects to support both 0.10 and 0.11.

So... what do folks prefer? I lean towards Plan 2. Please vote.

cc @djspiewak @pchlupacek @tpolecat @rossabaker

[pchlupacek]

+1 Plan 2

[pchiusano]

I also lean toward Plan 2. Within reason, better to just do 1 release with
breaking changes rather than 2.

On Wed, May 24, 2017 at 11:16 AM, Pavel Chlupacek [e-mail]
wrote:

+1 Plan 2

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/functional-streams-for-scala/fs2/issues/878#issuecomment-303756368,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAArQiw1QWeUYWiwy3P4Mmq4AKFIcqGOks5r9Em9gaJpZM4NlM7M
.

[tscholak]

+1 Plan 1 for reasons stated in Gitter.

[djspiewak]

I'm :+1: for Plan 1 because it gives topic/fast space to matriculate independent of the cats jump, but I'm not blind to the maintenance burden. I'm tempted to resolve that by just deprecating 0.9 immediately and only backporting emergency bugfixes. If the maintenance burden is going to be too significant though, Plan 2 is acceptable to me.

[tpolecat]

I'm in the same boat as @djspiewak I think.

I would prefer a cats-effect release sooner rather than later since doobie 0.5 will depend on its availability. Re: maintenance, If you were to deprecate 0.9, release 0.10 now, and then deprecate 0.10 when 0.11 comes out it wouldn't bother me at all; but I don't know what other downstream users expect. In general I only care about the latest release.

What concerns me about Plan 2 isn't so much the delay, but the potential that a problem in topic/fast could end up delaying cats-effect (which as I understand it is more or less done). However if you're confident that this isn't a big risk then I can track your milestones with doobie milestones and I that will be fine.

[rossabaker]

Under plan 1, would fs2-0.10 be released on cats-0.9? What is the anticipated timing of topic/fast vis-a-vis cats-1.0?

[mpilquist]

@rossabaker Yes, with plan 1, we'd build 0.10 on cats-0.9 and cats-effect 0.3. Then ideally, 0.11 releases against cats-1.0 and cats-effect 1.0.

[pchlupacek]

@rossabarker @mpilquist, I am really concerned about two major breaking changes. Could we perhaps do 0.10 and keep 0.9 for just bugfixes. When 0.10 will stabilize lets go for 1.0 ? I am relly mot sure we can comit for next 12 mnths to keep 3 releases in sync.

[mpilquist]

@pchlupacek I'm not clear on your proposal -- could you rephrase? Are you just asserting your preference for plan 2?

I'm not particularly concerned about the maintenance burden assuming 0.9 is for critical bug fixes only. I don't mind personally handling selective backports from series/0.11 to series/0.10. Once 0.11 ships, then 0.10 would get critical fixes only. I'm more concerned about all the downstream projects and introducing transitive dependency nightmares for people trying to use http4s with doobie with scodec-stream (for example).

Re: 0.11 incubation period -- now that we aren't calling it "1.0", I'm much less concerned with needing a long incubation period. The new interpreter is much, much simpler than 0.9.

I'd like to add another option -- plan 3, which is this: release 0.10.0-M1 based off current state of series/0.10. Then we merge topic/fast to series/0.10 before 0.10.0-M2. This gives downstream projects a stable version to build against and allows them to work with the cats bindings now, without making any maintenance or API commitments.

@tpolecat We can release cats-effect 0.3 now IMO. I don't see any developments in FS2 impacting cats-effect. The exception-aware-Free could potentially be used to implement the internals of IO differently, possibly with better performance, but that's something that folks can experiment with in the future (if ever).

[pchlupacek]

@mpilquist sorry to be not clear.

• I am voting for 2)
• This was just an argument why I really, really don't believe 1) is the option to go. Creating 2 vastly source incompatible versions in less than 6 months is something we shall avoid at any cost. If you are not concerned about back-porting costs, think about support costs, where people will have to say on which version they are (in case of troubles) and then you will have to replicate with their setup (because each 0.9, 0.10 and 0.11 may behave completely different way thanks to lower-level stuff that is changing between versions).

I really would like to go with 0.10 that is like your originally suggested 1.0 (all goodies included). I just think we shall re-name it 1.0 once we will battle test it in production code. This is what I understand option (2) is about.

Hope I am clear now and sorry for confusion earlier.

[xavier-fernandez]

+1 plan 1, I would rather make two small migrations than a big one.

[mpilquist]

Thanks everyone for your feedback. We've decided to go with plan 2 -- release 0.10 in late summer with milestones throughout the summer, including topic/fast.

I'm going to release 0.10.0-M1 tonight, based on series/0.10 and without the topic/fast work. I'll then release 0.10.0-M2 some time in the next couple of weeks with the topic/fast work.

Also, please kick the tires on topic/fast. As of yesterday, it's reliably passing all tests that 0.9 passes. Before M2, I'd like to have more documentation and I'd like to port the only remaining unported feature -- support for stepping pipes/pipe2s.