Faster release schedule?

[dakom]

Can we please have an initial minor-version release, and perhaps even have a policy that when crates are merged, they should be published at the same time- especially while it's pre-1.0?

I'm sure everyone wants gloo on crates.io, and there's no real need to elaborate further... but...

One of the best ways to increase adoption of Rust->WASM in general is to show actual usable demos on the web.

Yet one of the most essential building-blocks that will need to be there for pretty much any demo is going to be event listeners. gloo-events in particular is probably the right way to handle that. So holding it back might be having a bigger impact than it seems.

I guess it's debatable since nothing stops people from pulling in gloo from github and then building an app, but it does stop third-party higher level libraries from depending on gloo.

(for example, I'm currently stuck from publishing an update to awsm since I added gloo-events as a dependency)

[David-OConnor]

I propose we release the current items as a crate, and start adding things like fetch and router. We can change things later. Other things like an API for interchanging views should be straightfwd, albeit opinionated.

Discussion on Reddit from a few weeks ago

[Pauan]

@David-OConnor To be clear, the delay has not been because of our process, our goal has always been to release a minimal MVP version quickly.

But Nick is the owner of the gloo crate on crates.io, and he's been very busy with other things, so he hasn't been able to give any time to gloo.

But now I have ownership of it, so we can move forward.

[Pauan]

The initial version of gloo-console-timer, gloo-events, gloo-timers, and gloo have been published. 🎉