1.1: update site's extensions page + announce release date #1328
Conversation
Since we’re calling them ‘profiles’ now.
This makes the sidebar table of contents more useful imo (for us and, soon, in user-defined profiles).
Profile registration
|
Just a question: shouldn't the release of v1.1 wait until implementations start supporting the new features? This way, people could play with profiles and see if it is really usable in the wild. I say this because this is what the standard committee of PHP (PHP-FIG) also does: they require 2+ implementations before a standard can be accepted, and I believe it's very useful to test ideas before setting them in stone. Anyway, I have already started the adaption of JSON:API 1.1 in my PHP projects:
|
|
@kocsismate Thanks for raising this point. In the past, we've discussed adopting the same policy for finalizing new versions of the spec; specifically, at least two compliant implementations must exist for both the client and server side. I still think any final release date should be contingent upon this requirement. With that said, I think it's also important to set a target date to provide some motivation for implementors. |
In short, yes. My thinking was that 6 weeks should be enough time for that (especially as some implementers have already been working with profiles since #1268 was merged). However, I'm happy to use the criteria @dgeb proposed, and push the date back if we don't have two compliant implementations by January 15. |
|
Also, I've push another commit here that adds a changelog entry for the new features/changes in 1.1, since I imagine that will be helpful to implementers. (I'm pretty sure this list is complete, as I went through all the diffs since 1.0 came out.) |
Show the release date, when there is one, and add the concept of a “release candidate” stage (where the spec is subject to small changes based on implementor experience) vs a “working draft” stage (where we make no guarantees about what might still change, aside from our existing backwards compatibility promises).
|
Also, per conversation with @dgeb, I've pushed the date back to 1/31 and added an explicit mention of the two implementation requirement everywhere that the date occurs. |
The `/format/upcoming/` url still exists (in case it’s ever necessary to reference “the next version, whatever that may be at the time the link is followed”). However, it now simply redirects to `/format/1.1/` rather than having its own content. It’s status content previously was a bit confusing, and there wasn’t much reason for it to be a dedicated page. Additionally, it was confusing to have two links to v1.1 in the version picker (the upcoming link and the 1.1 permalink). So, now, the version picker excludes a separate permalink entry for v1.1, and instead has the picker entry for the “Upcoming spec” simply go to the `/format/1.1/` page.
|
Great job @ethanresnick - 1.1 here we come! 🎉 |
I too like this :) |
Note: only the last two commits are new here. (The others were already reviewed and merged in #1311, we just merged them into 1.1 branch rather than gh-pages.)