mirror of
https://gitee.com/hyperf/hyperf.git
synced 2024-11-29 18:27:44 +08:00
Release v3.1.36 (#7004)
Co-authored-by: Hanmo <32361024+Hanmo123@users.noreply.github.com>
This commit is contained in:
parent
0f63fdb3c9
commit
3558e6fab9
@ -1,4 +1,6 @@
|
||||
# v3.1.36 - TBD
|
||||
# v3.1.37 - TBD
|
||||
|
||||
# v3.1.36 - 2024-08-15
|
||||
|
||||
## Added
|
||||
|
||||
|
@ -1,5 +1,13 @@
|
||||
# Changelogs
|
||||
|
||||
# v3.1.36 - 2024-08-15
|
||||
|
||||
## Added
|
||||
|
||||
- [#6971](https://github.com/hyperf/hyperf/pull/6971) Added partitioned support for Cookie.
|
||||
- [#6990](https://github.com/hyperf/hyperf/pull/6990) Added support for retrieving the current system time with milliseconds for `Hyperf\Support\Traits\InteractsWithTime`.
|
||||
- [#6998](https://github.com/hyperf/hyperf/pull/6998) Added default methods for `#[AutoController]`. (You can add method `options` which used to support cors middleware)
|
||||
|
||||
# v3.1.35 - 2024-08-08
|
||||
|
||||
## Fixed
|
||||
|
@ -1,5 +1,13 @@
|
||||
# 版本更新记录
|
||||
|
||||
# v3.1.36 - 2024-08-15
|
||||
|
||||
## 新增
|
||||
|
||||
- [#6971](https://github.com/hyperf/hyperf/pull/6971) 为 `Cookie` 增加 `partitioned` 支持。
|
||||
- [#6990](https://github.com/hyperf/hyperf/pull/6990) 为 `Hyperf\Support\Traits\InteractsWithTime` 增加 `currentTimestampMs` 方法。
|
||||
- [#6998](https://github.com/hyperf/hyperf/pull/6998) 为注解 `#[AutoController]` 新增 `defaultMethods` 参数,你可以更加方便的设置 `Options` 方法,便于支持跨域中间件。
|
||||
|
||||
# v3.1.35 - 2024-08-08
|
||||
|
||||
## 修复
|
||||
|
@ -32,7 +32,7 @@
|
||||
|
||||
### 简化部署
|
||||
|
||||
在代码量庞大的 `单体架构(Monolithic architecture)` 系统中,即使只修改了一行代码,也需要重新部署整个系统才能够发布该变更,这种部署影响很大、风险很高,因此涉及到的干系人不敢轻易做部署,于是在实际的操作中部署的频率就不变得很低,版本与版本之间会对系统做了很多的功能或 `Bugfix`,并一次性将大量的变更一次性发布到生产环境中去,但两次发布之间的差异越大,出错的可能性就更大。
|
||||
在代码量庞大的 `单体架构(Monolithic architecture)` 系统中,即使只修改了一行代码,也需要重新部署整个系统才能够发布该变更,这种部署影响很大、风险很高,因此涉及到的干系人不敢轻易做部署,于是在实际的操作中部署的频率就会变得很低,版本与版本之间会对系统做了很多的功能或 `Bugfix`,并一次性将大量的变更一次性发布到生产环境中去,但两次发布之间的差异越大,出错的可能性就更大。
|
||||
当然在传统的 `PHP-FPM` 架构下的开发中,我们可能不会存在这样的问题,因为热更新是一种天然的存在,但利弊是同时存在的。
|
||||
|
||||
### 与组织架构相匹配
|
||||
|
@ -1,5 +1,13 @@
|
||||
# 版本更新記錄
|
||||
|
||||
# v3.1.36 - 2024-08-15
|
||||
|
||||
## 新增
|
||||
|
||||
- [#6971](https://github.com/hyperf/hyperf/pull/6971) 為 `Cookie` 增加 `partitioned` 支持。
|
||||
- [#6990](https://github.com/hyperf/hyperf/pull/6990) 為 `Hyperf\Support\Traits\InteractsWithTime` 增加 `currentTimestampMs` 方法。
|
||||
- [#6998](https://github.com/hyperf/hyperf/pull/6998) 為註解 `#[AutoController]` 新增 `defaultMethods` 參數,你可以更加方便的設置 `Options` 方法,便於支持跨域中間件。
|
||||
|
||||
# v3.1.35 - 2024-08-08
|
||||
|
||||
## 修復
|
||||
|
@ -32,7 +32,7 @@
|
||||
|
||||
### 簡化部署
|
||||
|
||||
在代碼量龐大的 `單體架構(Monolithic architecture)` 系統中,即使只修改了一行代碼,也需要重新部署整個系統才能夠發佈該變更,這種部署影響很大、風險很高,因此涉及到的干係人不敢輕易做部署,於是在實際的操作中部署的頻率就不變得很低,版本與版本之間會對系統做了很多的功能或 `Bugfix`,並一次性將大量的變更一次性發布到生產環境中去,但兩次發佈之間的差異越大,出錯的可能性就更大。
|
||||
在代碼量龐大的 `單體架構(Monolithic architecture)` 系統中,即使只修改了一行代碼,也需要重新部署整個系統才能夠發佈該變更,這種部署影響很大、風險很高,因此涉及到的干係人不敢輕易做部署,於是在實際的操作中部署的頻率就會變得很低,版本與版本之間會對系統做了很多的功能或 `Bugfix`,並一次性將大量的變更一次性發布到生產環境中去,但兩次發佈之間的差異越大,出錯的可能性就更大。
|
||||
當然在傳統的 `PHP-FPM` 架構下的開發中,我們可能不會存在這樣的問題,因為熱更新是一種天然的存在,但利弊是同時存在的。
|
||||
|
||||
### 與組織架構相匹配
|
||||
|
@ -1,5 +1,13 @@
|
||||
# 版本更新記錄
|
||||
|
||||
# v3.1.36 - 2024-08-15
|
||||
|
||||
## 新增
|
||||
|
||||
- [#6971](https://github.com/hyperf/hyperf/pull/6971) 為 `Cookie` 增加 `partitioned` 支援。
|
||||
- [#6990](https://github.com/hyperf/hyperf/pull/6990) 為 `Hyperf\Support\Traits\InteractsWithTime` 增加 `currentTimestampMs` 方法。
|
||||
- [#6998](https://github.com/hyperf/hyperf/pull/6998) 為註解 `#[AutoController]` 新增 `defaultMethods` 引數,你可以更加方便的設定 `Options` 方法,便於支援跨域中介軟體。
|
||||
|
||||
# v3.1.35 - 2024-08-08
|
||||
|
||||
## 修復
|
||||
|
@ -32,7 +32,7 @@
|
||||
|
||||
### 簡化部署
|
||||
|
||||
在程式碼量龐大的 `單體架構(Monolithic architecture)` 系統中,即使只修改了一行程式碼,也需要重新部署整個系統才能夠釋出該變更,這種部署影響很大、風險很高,因此涉及到的干係人不敢輕易做部署,於是在實際的操作中部署的頻率就不變得很低,版本與版本之間會對系統做了很多的功能或 `Bugfix`,並一次性將大量的變更一次性發布到生產環境中去,但兩次釋出之間的差異越大,出錯的可能性就更大。
|
||||
在程式碼量龐大的 `單體架構(Monolithic architecture)` 系統中,即使只修改了一行程式碼,也需要重新部署整個系統才能夠釋出該變更,這種部署影響很大、風險很高,因此涉及到的干係人不敢輕易做部署,於是在實際的操作中部署的頻率就會變得很低,版本與版本之間會對系統做了很多的功能或 `Bugfix`,並一次性將大量的變更一次性發布到生產環境中去,但兩次釋出之間的差異越大,出錯的可能性就更大。
|
||||
當然在傳統的 `PHP-FPM` 架構下的開發中,我們可能不會存在這樣的問題,因為熱更新是一種天然的存在,但利弊是同時存在的。
|
||||
|
||||
### 與組織架構相匹配
|
||||
|
Loading…
Reference in New Issue
Block a user