v1.0.0 needs to be issued

[jsumners]

With the GitHub project fast approaching 2,500 stars, people need to be able to have confidence that the library they are using is stable. Looking at the roadmap today (https://github.com/fastify/fastify/projects/1) I can see that a couple new issues were added (#135 and #121), but I think the authentication issue has been solved (https://github.com/fastify/fastify-auth and https://github.com/fastify/fastify-bearer-auth) well enough for 1.0.0.

In my opinion, @mcollina should be able to speak about 1.0.0 in his presentation at the beginning of October.

cc: @fastify/benchmarks

2017-09-24: I have segregated this list into "blocker" and "non-blockers". A non-blocker is an issue that we would like to have solved before 1.0.0, but isn't completely necessary. ~ jsumners

---

Todo (blockers):

• 404/500 routes (Custom routes for 404 and 500 #135)
• http caching headers (http caching headers #121)
• Add headers to validation schema (Add headers to validation schema #191)
• Add headers to request object (Add request.headers helper to avoid request.req.headers #200)
• Take a final decision in Proposal: remove request/reply and expose just context #169
• onSend hook (onSend hook #291)
• Fix printing stack traces Print stack trace of errors in handlers #258
• Allow payload to be modified in onSend (Modify the payload in the onSend hook #447)
• Fix this context on hooks (Hooks context #120)
• Remove reply.send(promise) (remove support reply.send(promise) #448)
• setNotFoundHandler is suppressing duplicated routes checking setNotFoundHandler is suppressing duplicated routes checking #451
• Remove callback from register remove callback from register, and remove error from .after() #460
• Support metadata in fastify-plugin Registering multiple plugins means ambiguous options #456 WIP: Plugins meta #466
• Update content parser API ContentType parser API #525
• avvio says it's already booted before fastify.listen is invoked avvio says it's already booted before fastify.listen is invoked #491 Start loading the plugins only when calling .ready, .inject or .listen #561
• Drop Boom support Drop Boom support #542 Updated error handling #558
• Use http-errors for generating errors Use http-errors #543 Use http-errors #571

Todo (non-blockers):

• Refactor documentation to separate concerns (intro vs reference) (Rethinking for docs #296)
• Finish off fastify-swagger First implementation fastify-swagger#1

[delvedor]

Features that we must implement before 1.0.0:

• 404/500 routes (Custom routes for 404 and 500 #135)
• http caching headers (http caching headers #121)
• Add headers to validation schema (Add headers to validation schema #191)
• Add headers to request object (Add request.headers helper to avoid request.req.headers #200)
• Finish the implementation of fastify-swagger
• Take a final decision in Proposal: remove request/reply and expose just context #169

Feel free to add this list in your first comment as placeholder :)

[jsumners]

@delvedor you should have permissions to be able to edit the post. I am completely fine with that.

[delvedor]

@delvedor you should have permissions to be able to edit the post. I am completely fine with that.

Done :)

[cagataycali]

For first stable version, this proposals looks good for me! 🎉

[jsumners]

I disagree with #169 being a blocker for 1.0.0. That is clearly a divisive proposal and unlikely to be settled any time soon.

[delvedor]

I disagree with #169 being a blocker for 1.0.0. That is clearly a divisive proposal and unlikely to be settled any time soon.

Yes, and since it is a divisive proposal I think we should take a final decision on that.
If we keep req, reply we should provide a better way to help user interact with both request and reply at the same time when creating a plugin.

[StarpTech]

I would add this to the list #258

[mcollina]

@StarpTech done.

[StarpTech]

Hi, why is swagger a blocker for a major release?

[jsumners]

@StarpTech for me, it's not. But I understand why it is. Fastify's goal is for writing RESTful API servers. Thus, it would be good to be able to support documenting those APIs. I think things like Swagger are way more trouble than they're worth (the code for Swagger to read ends up being more than the actual method), but there's a lot of people that like it.

[StarpTech]

Ok, I understand it but it's still a plugin and not part of the core. Is anybody working on it? Should we discuss some proposals about the integration with fastify e.g configuration approach vs comments?

[mcollina]

The actual problem for 1.0.0 is that we had semver-major changes in the last 5 minor releases. I think our API has not settled yet.

[mcollina]

I propose we drop fastify-swagger from the list. We can ship it later. 404 and 500 have already a PR open.. is there anyone that wants to add support for the http caching headers in Request and Reply, similar to what Hapi does?

[jsumners]

+1 to Swagger not being a blocker.

I'm not entirely sure what needs to be done to tackle #121.

[allevo]

I'd like to add #296 to this list

[jsumners]

@allevo done.

[StarpTech]

Http-Caching is done? #121

[jsumners]

No. It just has its own repository.

[StarpTech]

But what's the milestone in caching?

[jsumners]

There is discussion about it in the issue tracker on that repo. But the short of it is that I am currently running for office in my city and don't have free time to work on it. Thankfully, the final Election Day is November 7.

[jsumners]

Blockers list updated with closing of onSend and addition of two new items.

[mcollina]

Thanks!

[jsumners]

@fastify/fastify please re-review the blockers list. There is only one open at this time. Make sure there are not any others that should be there.

[allevo]

I'd like to finish the discussion #169

[jsumners]

Accidental close. Reopened.

[jsumners]

It's clear in #709 that we definitely need to get this issue resolved. It looks like we have one bug outstanding (#693), and it doesn't seem to be affecting many people. I think we should be issuing an rc release promptly.

[mcollina]

@jsumners that should be solved in the RC phase.

[jsumners]

I think v1.0.0-rc1 should be released this week. What say you @fastify/fastify ?

[allevo]

@jsumners A breaking-change issue is opened #718. #727 is another breaking-change.

[delvedor]

I'd love to release a rc as soon as possible, but currently we have two breaking changes proposed. That's too much. I think that if in a week we do not found anything that could cause a breaking change, then we can release an rc and consider the api stable enough.

[allevo]

I think that if in a week we do not found anything that could cause a breaking change

Apparently, it seems a bit difficult 😃

[delvedor]

@allevo that's not a problem, we do not have any fixed date, we just want to deliver a good and stable api before release v1 and I think no one can complain with this.

[jsumners]

The issue is that we can come up with a breaking change every week. We, as programmers, will always see a better way to do a thing we have already done and seek to change it. No, there isn't a date set for release (I'd argue that there should be one), but as has been shown in the past couple of weeks, there are people already relying on Fastify with its current API. We need to lock it down very soon or risk losing the traction already gained.

I think the current PRs labeled as breaking can be resolved in short order. That's why I think an rc1 can be issued this week.

[Ethan-Arrowood]

I don't know sort of plans you have for releasing 1.0.0, but if we are interested in publishing a blog post I have a good relationship with the FreeCodeCamp publication on Medium and could help facilitate a release article. (Would be happy to help write it as well).

[mcollina]

I think we can do as many rcs as we like. Let’s target next monday.

[delvedor]

The first release candidate is out! 🎉
https://github.com/fastify/fastify/releases/tag/v1.0.0-rc.1

[mcollina]

Fastify has come a long way! Should we pick a date and release then? I do not want to keep the rc going for more than 2-3 weeks.

[jsumners]

March 1?

[mcollina]

I like March 1!

[jsumners]

Looks like people have voted that March 1 be the v1.0.0 target date.

[yamalight]

@jsumners maybe it's also worth releasing RC versions for all official extensions?
at least some of them are currently incompatible with 1.0-rc1

[jsumners]

@yamalight it's up to the maintainers of the plugins to do that. I released updates yesterday for the ones I maintain. PRs to currently incompatible plugins would be helpful. Basically, they need:

module.exports = fp(plugin, {
  fastify: '>=1.0.0-rc.1',
  name: 'foo-plugin'
})

And after the rc phase, they should change the minimum version to ^1.0.0.

[Ethan-Arrowood]

@jsumners I'll make some prs against the JWT libraries later today

[allevo]

I'd like to wait for delvedor/find-my-way#60

[delvedor]

If someone wants to give a try to that issue be my guest!
I'll give it an eye asap, but at the moment I'm stuck at work.

[delvedor]

The router bug has been fixed.
The v1.0.0 release is planned for the 5th of march! (unless very serious bugs comes out)

[delvedor]

I guess we can close this one :)

https://medium.com/@fastifyjs/fastify-goes-lts-with-1-0-0-911112c64752