Skip to content

Commit 17e2204

Browse files
ntottenntotten
committed
Added doc on new env variable
1 parent 99ac46e commit 17e2204

File tree

3 files changed

+92
-89
lines changed

3 files changed

+92
-89
lines changed

‎docs/articles/compatibility-dates.md

+83
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,83 @@
1+
---
2+
title: Compatibility Dates
3+
---
4+
5+
Zuplo is constantly shipping updates to the underlying runtime of projects.
6+
Occasionally, these updates aren't backwards compatible. In order to ensure that
7+
your project continues to build, deploy and operate as you expect it you can set
8+
a compatibility date to lock in the behavior and APIs of the runtime.
9+
10+
## 2024-01-15
11+
12+
This compatibility date includes a number of minor breaking changes to improve
13+
the overall behavior of Zuplo APIs. This compatibility date is the default for
14+
any projects created after Feb. 23rd, 2024.
15+
16+
### Outbound Handlers on all Response Statuses
17+
18+
Previously, outbound handlers would only run on response status ranging from
19+
200-299. Now outbound handlers will always run, regardless of the response code.
20+
21+
### No Hooks on System Routes
22+
23+
Previously runtime hooks such as `OnRequest` or `OnResponseSending` would run on
24+
system routes. For example, if you are using our Developer Portal and have it
25+
running on `/docs`, before this change you could write a hook that modified the
26+
output of the Developer Portal.
27+
28+
### Remove Cloudflare Location Headers
29+
30+
Previously, some Cloudflare location headers (for example `cf-ipregion`) could
31+
be passed through your Zuplo gateway. Now these headers are always removed from
32+
the outbound request if they have been set. If you need access to geo-location
33+
data use [`context.incomingRequestProperties`](./zuplo-context.md) instead.
34+
35+
## 2024-01-15
36+
37+
This compatibility date includes a several breaking changes to improve the
38+
overall behavior of Zuplo APIs. This compatibility date is the default for any
39+
projects created after Jan. 15th, 2024.
40+
41+
### Run Outbound Policies on All Responses
42+
43+
Previously, outbound policies would only run on response status ranging from
44+
200-299. Now outbound policies will always run, regardless of the response code.
45+
46+
### No Hooks on System Routes
47+
48+
Previously runtime hooks such as `OnRequest` or `OnResponseSending` would run on
49+
system routes. For example, if you are using our Developer Portal and have it
50+
running on `/docs`, before this change you could write a hook that modified the
51+
output of the Developer Portal. This could result in unexpected behavior and is
52+
now disallowed.
53+
54+
### Remove Cloudflare Location Headers
55+
56+
Zuplo routes all requests through Cloudflare. Cloudflare adds a number of
57+
headers to requests. Previously, some Cloudflare location headers (for example
58+
`cf-ipregion`) could be passed through your Zuplo gateway. Now these headers are
59+
always removed from the outbound request if they have been set. If you need
60+
access to geo-location data use
61+
[`context.incomingRequestProperties`](./zuplo-context.md) instead.
62+
63+
## 2024-03-14
64+
65+
This compatibility date doesn't include any breaking changes. However, Zuplo
66+
made a number of changes to the runtime build process. These changes will allow
67+
a number of future improvements. Out of an abundance of caution, these changes
68+
are only enabled for projects that have set their compatibility date to
69+
`2024-03-14`. This compatibility date is the default for any projects created
70+
after March 14th, 2024.
71+
72+
Over time, the build changes will be enabled by default on all future
73+
deployments regardless of compatibility date. Existing customers are encouraged
74+
to update their compatibility date to `2024-03-14` and test their projects to
75+
ensure that they continue to operate as expected.
76+
77+
We expect that this new build process will roll out to all customers (regardless
78+
of compatibility date) by the end of April 2024.
79+
80+
## 2024-09-02
81+
82+
The compatibility date allows the ability to call `fetch` to hosts with custom
83+
ports. Previously only the standard ports (80, 443) were allowed.

‎docs/articles/environment-variables.md

+2
Original file line numberDiff line numberDiff line change
@@ -123,3 +123,5 @@ use in your code:
123123
deployed.
124124
- `ZUPLO_BUILD_ID` - The build ID of the environment. This is a unique ID for
125125
each build of the environment. This is a UUID.
126+
- `ZUPLO_COMPATIBILITY_DATE` - The
127+
[compatibility date](./compatibility-dates.md) of runtime environment.

‎docs/articles/zuplo-json.md

+7-89
Original file line numberDiff line numberDiff line change
@@ -26,94 +26,12 @@ provider or by pushing a local change with git. If your project doesn't have a
2626

2727
:::
2828

29-
## Compatibility Date
29+
## Compatibility Dates
3030

31-
Zuplo is constantly shipping updates to the underlying runtime of projects.
32-
Occasionally, these updates aren't backwards compatible. Additionally, Zuplo
33-
deploys portions of projects to Cloudflare Workers who also occasionally make
34-
non-backward compatible changes. In order to ensure that your project continues
35-
to build, deploy and operate as you expect it you can set a compatibility date
36-
to lock in the behavior and APIs of the runtime.
31+
The `compatibilityDate` field in the `zuplo.jsonc` file allows you to lock in
32+
the bevaior of the runtime environment for your project. This is useful if you
33+
want to ensure that your project continues to build, deploy and operate as you
34+
expect it to.
3735

38-
Current valid settings for the compatibility date are to not have it set or to
39-
set it to `2023-03-14`. When not set, the Zuplo runtime doesn't set a
40-
compatibility date on Cloudflare Workers. When the value is set to `2023-03-14`,
41-
the value is also set on the Cloudflare Worker which enables all changes up to
42-
March 14, 2023. See
43-
[Cloudflare's documentation](https://developers.cloudflare.com/workers/platform/compatibility-dates/)
44-
for a list of changes.
45-
46-
## 2024-01-15
47-
48-
This compatibility date includes a number of minor breaking changes to improve
49-
the overall behavior of Zuplo APIs. This compatibility date is the default for
50-
any projects created after Feb. 23rd, 2024.
51-
52-
### Outbound Handlers on all Response Statuses
53-
54-
Previously, outbound handlers would only run on response status ranging from
55-
200-299. Now outbound handlers will always run, regardless of the response code.
56-
57-
### No Hooks on System Routes
58-
59-
Previously runtime hooks such as `OnRequest` or `OnResponseSending` would run on
60-
system routes. For example, if you are using our Developer Portal and have it
61-
running on `/docs`, before this change you could write a hook that modified the
62-
output of the Developer Portal.
63-
64-
### Remove Cloudflare Location Headers
65-
66-
Previously, some Cloudflare location headers (for example `cf-ipregion`) could
67-
be passed through your Zuplo gateway. Now these headers are always removed from
68-
the outbound request if they have been set. If you need access to geo-location
69-
data use [`context.incomingRequestProperties`](./zuplo-context.md) instead.
70-
71-
## 2024-01-15
72-
73-
This compatibility date includes a several breaking changes to improve the
74-
overall behavior of Zuplo APIs. This compatibility date is the default for any
75-
projects created after Jan. 15th, 2024.
76-
77-
### Run Outbound Policies on All Responses
78-
79-
Previously, outbound policies would only run on response status ranging from
80-
200-299. Now outbound policies will always run, regardless of the response code.
81-
82-
### No Hooks on System Routes
83-
84-
Previously runtime hooks such as `OnRequest` or `OnResponseSending` would run on
85-
system routes. For example, if you are using our Developer Portal and have it
86-
running on `/docs`, before this change you could write a hook that modified the
87-
output of the Developer Portal. This could result in unexpected behavior and is
88-
now disallowed.
89-
90-
### Remove Cloudflare Location Headers
91-
92-
Zuplo routes all requests through Cloudflare. Cloudflare adds a number of
93-
headers to requests. Previously, some Cloudflare location headers (for example
94-
`cf-ipregion`) could be passed through your Zuplo gateway. Now these headers are
95-
always removed from the outbound request if they have been set. If you need
96-
access to geo-location data use
97-
[`context.incomingRequestProperties`](./zuplo-context.md) instead.
98-
99-
## 2024-03-14
100-
101-
This compatibility date doesn't include any breaking changes. However, Zuplo
102-
made a number of changes to the runtime build process. These changes will allow
103-
a number of future improvements. Out of an abundance of caution, these changes
104-
are only enabled for projects that have set their compatibility date to
105-
`2024-03-14`. This compatibility date is the default for any projects created
106-
after March 14th, 2024.
107-
108-
Over time, the build changes will be enabled by default on all future
109-
deployments regardless of compatibility date. Existing customers are encouraged
110-
to update their compatibility date to `2024-03-14` and test their projects to
111-
ensure that they continue to operate as expected.
112-
113-
We expect that this new build process will roll out to all customers (regardless
114-
of compatibility date) by the end of April 2024.
115-
116-
## 2024-09-02
117-
118-
The compatibility date allows the ability to call `fetch` to hosts with custom
119-
ports. Previously only the standard ports (80, 443) were allowed.
36+
Refer to the [documentation](./compatibility-dates.md) for compatibility dates
37+
and their changes.

0 commit comments

Comments
 (0)