[Discussion] 0.1 release criteria

[aturon]

Let's brainstorm about what we'd like to get done before making a 0.1 release to crates.io!

[aturon]

The most obvious blockers:

• More thorough documentation, especially around the routing syntax and semantics
• Additional, larger examples

Less clear:

• Possibly a "Guide" or other book-like piece of documentation to help people get going?

Are there other core pieces of functionality people feel are vital for a 0.1 release? Personally, I don't think 0.1 should mean "production ready", and we should feel free to iterate heavily and release (and blog) often as we develop.

Thoughts?

[tirr-c]

It will be nice if we have these features:

• Custom default handler (Customize route failure response #10)
  • @tzilist is implementing this.
  • In addition, we might want to run a chain of middleware even if routing fails. Some middleware like compression should run regardless of the routing result.
• Configuration (Add configuration (for extractors and middleware) #5)
  • I have a vague idea on the design, which can cover default configuration, initialization from file/env, and per router/endpoint overriding. But we don't need to implement all at once; I think it's okay to start with defaults and overriding.

[sendilkumarn]

For 0.1, would love to see #51 landing. This will enable us to create a complete web app (easily) with a separate frontend with any framework and backend with tide and diesel.

P.S. I have a working example with tide + diesel + frontend.

[aturon]

@tirr-c

In addition, we might want to run a chain of middleware even if routing fails. Some middleware like compression should run regardless of the routing result.

Yeah, I was wondering how we might want to approach that. Want to open up an issue for further discussion?

I'm going to set up a 0.1 milestone and we can start marking issues, including the ones y'all have mentioned here. I'll also open some additional issues around docs.

[aturon]

OK, here's the 0.1 milestone, populated with most of the things mentioned here, other than a new issue for "always-applied" middleware.

[aturon]

@sendilkumarn

I have a working example with tide + diesel + frontend.

😍

[tirr-c]

Opened #61 and added it to the milestone.

[tzilist]

@tirr-c

In addition, we might want to run a chain of middleware even if routing fails. Some middleware like compression should run regardless of the routing result.

Yeah, I was wondering how we might want to approach that. Want to open up an issue for further discussion?

I'm going to set up a 0.1 milestone and we can start marking issues, including the ones y'all have mentioned here. I'll also open some additional issues around docs.

In regards to this, I am thinking that I will have the router handle this instead of how we are handling it here. I suppose my idea here is that instead of having to have separate logic around whether a route is found or not, the user can just specify a response (just like any other endpoint) and the middleware will behave the same. Not sure what you guys think about this but let me know :)

[tzilist]

Here is my braindump of things I'd like to see

• I'll echo @sendilkumarn comment and even expand on it. I think tide should handle OPTION, CONNECT and TRACE automatically.
• Finalize config spec as @tirr-c mentioned. Specifically, we really should have a way to handle compilation configs and runtime configs.
• Static file handling
• (Maybe) CORS middleware
• diesel/r2d2/ examples. Possibly how to make these async if at all possible.
• templating examples

[bIgBV]

I'll echo on a couple of points:

• Compile time and runtime configuration
• Staticfile serving
• Templating examples.

I'd like to see some sort of logging infrastructure provided for users of Tide as a part of 0.1, but I don't think it is a blocking concern.

One thing I would definitely like is a guide talking about the concepts in Tide. Because right now to me the way extractors and endpoints work (especially with named path parameters) seems like magic 😅

[aturon]

cc @killercup

[aturon]

@tzilist @bIgBV would you mind opening issues for the items on your lists that don't have issues yet? I'll get them tagged and on the milestone, and that way we'll have a good place to talk through the design as well!

[yoshuawuyts]

I'd like to propose we start doing regular releases soon. I think it's beneficial if people have a convenient way to test out tide, creating a tighter feedback cycle. For example this could help explore the design space of #99.

There seems to be significance attached to the 0.1 label, so perhaps we should start with 0.0.1. Ideally this could be done in the next few days, mostly waiting on #109 to be merged.

How do people feel about this? ✨

[davidbarsky]

@yoshuawuyts I said this on Discord, but I'd be in favor of alpha releases starting with 0.0.1 with a “0.1” release being marked as a “pretty solid beta”.

[aturon]

I personally would also be OK with going straight for 0.1 and then doing additional major releases (0.2 etc) as we go. Either way. I think what's important at the end of the day is just being clear to the broader community about what the releases represent and what to expect.

[tirr-c]

+1 to 0.0.1. Tide will be used more and we'll get more feedback if we release early. Also, version 0.0.1 would indicate that we'll move fast and break compatibility more often.

[yoshuawuyts]

Going with a 0.0.1 release seems to be the least controversial option, so that might be the best to start with for now.

Personally I'm a big fan of starting every semver cycle at 1.0.0 because it allows version numbers to be meaningful (breaking|feature|bugfix). I think after we start doing regular releases it would be good to start thinking about the core feature set that a 1.0.0 release should contain so our version numbers can start reflecting the API changes we make. We should probably discuss what that entails in a separate issue.

[bIgBV]

@yoshuawuyts +1 to starting semver from 1.0.0

So what do you think is missing right now from the 0.0.1 release? Do we want to discuss that here or in a separate issue?

[yoshuawuyts]

@bIgBV I was thinking we just start releasing under 0.0.x. I'm thinking more of doing it as a way to make installation easier, not make

[yoshuawuyts]

[email protected] has been released! - https://docs.rs/tide/0.0.1/tide/

[aturon]

Huzzah!

I think it'd be great to plan to accompany releases with a blog post, like the updates in this post.

[yoshuawuyts]

@aturon ah yes, excellent point! I'm not completely comfortable yet writing posts, but there's no better time to start I guess ✨

[killercup]

FYI, I've been meaning to write a post on the extractor pattern, which I believe tide uses as well.

…

On Mon, 21 Jan 2019, 07:34 Yoshua Wuyts, ***@***.***> wrote: @aturon <https://github.com/aturon> ah yes, excellent point! I'm not completely comfortable yet writing posts, but there's no better time to start I guess ✨ — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#60 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABOX8yg9qaoKKGZKRoLpqhPkVN3Gh7Iks5vFV-FgaJpZM4Yx6GM> .

[yoshuawuyts]

0.1 has been released, and we're regularly releasing new versions now. I think it's safe to close this (: