New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v1.0.0 needs to be issued #229

Closed
jsumners opened this Issue Sep 15, 2017 · 88 comments

Comments

Projects
None yet
10 participants
@jsumners
Member

jsumners commented Sep 15, 2017

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 (#135)
  • http caching headers (#121)
  • Add headers to validation schema (#191)
  • Add headers to request object (#200)
  • Take a final decision in #169
  • onSend hook (#291)
  • Fix printing stack traces #258
  • Allow payload to be modified in onSend (#447)
  • Fix this context on hooks (#120)
  • Remove reply.send(promise) (#448)
  • setNotFoundHandler is suppressing duplicated routes checking #451
  • Remove callback from register #460
  • Support metadata in fastify-plugin #456 #466
  • Update content parser API #525
  • avvio says it's already booted before fastify.listen is invoked #491 #561
  • Drop Boom support #542 #558
  • Use http-errors for generating errors #543 #571

Todo (non-blockers):

@delvedor delvedor added the discussion label Sep 15, 2017

@delvedor

This comment has been minimized.

Member

delvedor commented Sep 15, 2017

Features that we must implement before 1.0.0:

  • 404/500 routes (#135)
  • http caching headers (#121)
  • Add headers to validation schema (#191)
  • Add headers to request object (#200)
  • Finish the implementation of fastify-swagger
  • Take a final decision in #169

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

@jsumners

This comment has been minimized.

Member

jsumners commented Sep 15, 2017

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

@delvedor

This comment has been minimized.

Member

delvedor commented Sep 15, 2017

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

Done :)

@cagataycali

This comment has been minimized.

Contributor

cagataycali commented Sep 15, 2017

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

@jsumners

This comment has been minimized.

Member

jsumners commented Sep 16, 2017

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

This comment has been minimized.

Member

delvedor commented Sep 17, 2017

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

This comment has been minimized.

Member

StarpTech commented Sep 19, 2017

I would add this to the list #258

@mcollina

This comment has been minimized.

Member

mcollina commented Sep 20, 2017

@StarpTech done.

@StarpTech

This comment has been minimized.

Member

StarpTech commented Sep 21, 2017

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

@jsumners

This comment has been minimized.

Member

jsumners commented Sep 21, 2017

@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

This comment has been minimized.

Member

StarpTech commented Sep 21, 2017

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

This comment has been minimized.

Member

mcollina commented Sep 21, 2017

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

This comment has been minimized.

Member

mcollina commented Sep 23, 2017

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

This comment has been minimized.

Member

jsumners commented Sep 23, 2017

+1 to Swagger not being a blocker.

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

@allevo

This comment has been minimized.

Member

allevo commented Sep 24, 2017

I'd like to add #296 to this list

@jsumners

This comment has been minimized.

Member

jsumners commented Sep 24, 2017

@allevo done.

@StarpTech

This comment has been minimized.

Member

StarpTech commented Oct 23, 2017

Http-Caching is done? #121

@jsumners

This comment has been minimized.

Member

jsumners commented Oct 23, 2017

No. It just has its own repository.

@StarpTech

This comment has been minimized.

Member

StarpTech commented Oct 23, 2017

But what's the milestone in caching?

@jsumners

This comment has been minimized.

Member

jsumners commented Oct 23, 2017

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

This comment has been minimized.

Member

jsumners commented Oct 30, 2017

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

@mcollina

This comment has been minimized.

Member

mcollina commented Oct 30, 2017

Thanks!

@jsumners

This comment has been minimized.

Member

jsumners commented Nov 5, 2017

@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

This comment has been minimized.

Member

allevo commented Nov 6, 2017

I'd like to finish the discussion #169

@jsumners jsumners closed this Nov 6, 2017

@jsumners jsumners reopened this Nov 6, 2017

@jsumners

This comment has been minimized.

Member

jsumners commented Nov 6, 2017

Accidental close. Reopened.

@mcollina

This comment has been minimized.

Member

mcollina commented Jan 16, 2018

There are a few breaking changes in master, plus a couple of outstanding PRs.
I would issue another minor with what we have on master + outstanding PRs, and then some RCs.
We should figure out some LTS strategy.

@Ethan-Arrowood

This comment has been minimized.

Contributor

Ethan-Arrowood commented Jan 16, 2018

Something I discovered recently is that travis.ci lets you have build stages now so we could run the unit tests in multiple version of node in order to maintain LTS

@jsumners jsumners referenced this issue Jan 16, 2018

Closed

LTS strategy #670

@jsumners

This comment has been minimized.

Member

jsumners commented Jan 24, 2018

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

This comment has been minimized.

Member

mcollina commented Jan 25, 2018

@jsumners that should be solved in the RC phase.

@jsumners

This comment has been minimized.

Member

jsumners commented Jan 30, 2018

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

@allevo

This comment has been minimized.

Member

allevo commented Jan 30, 2018

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

@delvedor

This comment has been minimized.

Member

delvedor commented Jan 30, 2018

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

This comment has been minimized.

Member

allevo commented Jan 30, 2018

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

This comment has been minimized.

Member

delvedor commented Jan 30, 2018

@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

This comment has been minimized.

Member

jsumners commented Jan 30, 2018

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

This comment has been minimized.

Contributor

Ethan-Arrowood commented Jan 30, 2018

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

This comment has been minimized.

Member

mcollina commented Jan 31, 2018

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

@delvedor

This comment has been minimized.

Member

delvedor commented Feb 5, 2018

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

@mcollina

This comment has been minimized.

Member

mcollina commented Feb 8, 2018

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

This comment has been minimized.

Member

jsumners commented Feb 8, 2018

March 1?

@mcollina

This comment has been minimized.

Member

mcollina commented Feb 8, 2018

I like March 1!

@jsumners

This comment has been minimized.

Member

jsumners commented Feb 12, 2018

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

@yamalight

This comment has been minimized.

Contributor

yamalight commented Feb 12, 2018

@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

This comment has been minimized.

Member

jsumners commented Feb 12, 2018

@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

This comment has been minimized.

Contributor

Ethan-Arrowood commented Feb 12, 2018

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

Ethan-Arrowood added a commit to Ethan-Arrowood/fastify-jwt that referenced this issue Feb 13, 2018

Ethan-Arrowood added a commit to Ethan-Arrowood/fastify-jwt-authz that referenced this issue Feb 13, 2018

@allevo

This comment has been minimized.

Member

allevo commented Feb 27, 2018

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

@delvedor

This comment has been minimized.

Member

delvedor commented Feb 27, 2018

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

This comment has been minimized.

Member

delvedor commented Mar 2, 2018

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

This comment has been minimized.

Member

delvedor commented Mar 6, 2018

@delvedor delvedor closed this Mar 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment