search

async-interop / event-loop

An event loop interface for interoperability in PHP.
MIT License
169 stars 9 forks source link

Version 1 #119

Closed mbonneau closed 7 years ago

mbonneau commented 7 years ago

I have a lot invested in async PHP and am excited about the future. I am grateful to all the time and thought that has gone into this spec by many different people and look forward to having all libraries use this common standard so that I don't have to reimplement libraries just because they don't support my flavor of event loop.

I would like to suggest that the current draft of the event-loop be used as version 1. The discussions on the issues are not show-stopper issues and could be debated for the next version of the spec.

If there are objections to releasing version 1, a feature freeze and a discussion of a concrete list of items that must be resolved may be an alternative. This would give everyone an idea of how long the wait may be and whether or not development efforts on implementor's side or user's side should use async-interop's loop.

There is a catch-22 in releasing a spec or library - everyone wants things to be perfect before it is released, but to find the rough spots you need users, and to get users, you need a release. So let's release!

bwoebi commented 7 years ago

I largely agree here.

I'd just love to have the current issues left resolved, and then I'm all for a first release. If we all collaborate as actively as today on resolving the current issues, I'm pretty sure we could release it in a few days already.

mbonneau commented 7 years ago

@bwoebi - Can a v1 milestone be created and someone can tag the issues that need to be resolved for release?

WyriHaximus commented 7 years ago

@mbonneau @bwoebi just created that milestone: https://github.com/async-interop/event-loop/milestone/1

WyriHaximus commented 7 years ago

Also agreeing strongly here, I rather tag a 1.1 or 2.0 in a month or two than keep making everything perfect, we're creating software, it will be never be completely done so it will never be perfect :smile:

kelunik commented 7 years ago

@WyriHaximus I just tagged all of the issues and added them to it.

I strongly advise against having a 2.0 soon. Everything that breaks BC should be resolved before 1.0, otherwise we end up with incompatible libraries again.

WyriHaximus commented 7 years ago

@kelunik awesome :+1:

Very true, we could also go for 0.4 as a (by lack of better translation) final rehearsal before going to 1.0.

mbonneau commented 7 years ago

@WyriHaximus - I would rather see version 2.0 and 3.0 in a month than not have a release - think of all the users you would have reporting issues - and all the refinement the project would have gone through.

kelunik commented 7 years ago

@mbonneau In that case you can just use the existing tags and base your work on those? Why does it need to be 1.0 and 2.0 instead of 0.4 and 1.0?

bwoebi commented 7 years ago

@kelunik A 1.0 release is sending somewhat of a signal, a 0.4 is just another in dev version.

WyriHaximus commented 7 years ago

@kelunik 1.0 is ought to be more mature than 0.x. We know better in this case, but it could be perceived by others differently.

kelunik commented 7 years ago

@bwoebi @WyriHaximus Then we just need to communicate that better.

But as long as you all keep being as active as today, I don't see an issue with releasing it soon.

WyriHaximus commented 7 years ago

Yeah today was crazy, well done :+1:

kelunik commented 7 years ago

Closing this one, we have a milestone set.