是否在准备放大招？半年木有更新了，6.1大版本？

[hulang]

https://github.com/top-think/framework/issues/2638 只求升级下：league/flysystem，1.0和很多包冲突了。。自己又太菜，无法自己开个分支。

[liu21st]

这个库不同版本之间不兼容 所以不方便升级库

[hulang]

@liu21st 很多扩展都使用league/flysystem v2，没法安装啊，难道6.0.x版本一直v1用到：LTS 周期结束？

[augushong]

或许可以做成扩展，实现一个版本管理器。回头试试。

[hulang]

@augushong 整个：top-think/framework/issues ,都是你在帮忙回复。。开发好了吗？

[augushong]

没有，事多。过段时间有精力了再说吧。

[augushong]

这个就算实现了，也有点偏门，还得看官方的意思。

我的思路就是，把本身对flysystem的使用的方法做个抽象接口，然后做一个对此的composer扩展，比如叫think-flysystem,v1,v2,v3, 每个版本都对应相应的flysystem。

这样应该不影响框架上层的使用。如果需要切换flysystem的版本，先切换think-flysystem的版本就好了。

最近没精力做，而且影响太大，得慎重。最终也得官方出面。

[augushong]

flysystem的v1版本确实有问题，能升级最好。

[hulang]

@augushong 官方6x版本，LTS 结束都不会更新了。。 有时候，想装别人的扩展。。 一碰有flysystem v2或以上的，就不行。。 我认为的就修改flysystem目录中的3个文件，无论的：长痛不如短痛，一劳永逸的词。只能说说而已了。。

[yuanzhihai]

我修改了一下升级到了flysystem v2  本地测试可以用 等官方来测试看看

[hulang]

@yzh52521 给力啊。。一直用老大你的好几个扩展。。

[yuanzhihai]

还要等官方的测试 和 合并 测试用例 我也不会写 @hulang

[hulang]

@yzh52521 本地测试可以用，应该木有问题。 你再装下你的。https://github.com/yzh52521/thinkphp-filesystem-cloud 开个v2的分支，进行flysystem v2 化，进行测试，OK，就O了。

[augushong]

你这个提交不太可能接受的，这变动相当于开一个6.1的版本了。

如果能做到无缝升级，在经过充分测试，应该还好办。

[yuanzhihai]

就是改了一下 flystem 的两个文件 配置不需要改动 可以无缝升级的

[augushong]

但是使用了flysystem v1的用户是不能升级的，依赖会冲突的。尤其是一些二开后台，早就集成了很多第三方的存储。

[augushong]

之所以不做这个改动，其实就是因为目前都是基于flysystem 1的生态。这样相当于放弃了

[yuanzhihai]

但是使用了flysystem v1的用户是不能升级的，依赖会冲突的。尤其是一些二开后台，早就集成了很多第三方的存储。

你说的也对，可以做成扩展，但是 官方框架集成了 除非框架移除这个

[augushong]

是的，这个方法有点偏门，但是并没有什么问题。 而且框架本身就把很多通用方法独立成扩展了，比如：think-helper。 这样做也比较符合框架的调性。 也不需要很大的决心，毕竟不会影响旧的生态。

[yuanzhihai]

现在 不升级 composer 安装框架 总是 提示 Found 1 security vulnerability advisory affecting 1 package.

[augushong]

哈哈，composer的新版本加上了风险提示。这就更容易推动这样的更新。

[yuanzhihai]

等待吧

[augushong]

主要是贡献者太少了。白嫖的更是减分。难

[hulang]

但是使用了flysystem v1的用户是不能升级的，依赖会冲突的。尤其是一些二开后台，早就集成了很多第三方的存储。

关于无缝升级，只是本地，完全OK。。如果是第三方，可以在发布版本的时候告知，已升级flysystem ^v2 至于官方是否合并的事，我就说了嘛，长痛不如短痛/一劳永逸 或 墨守成规 的抉择了。

[augushong]

不是你说的这样的。 你其实也完全可以fork一份仓库，然后再composer指定自己的源。不再用官方的源。对于一个项目来说是完全可以的。

这也不是墨守成规，也不是发个通知就完事了的。

[hulang]

不是你说的这样的。 你其实也完全可以fork一份仓库，然后再composer指定自己的源。不再用官方的源。对于一个项目来说是完全可以的。

这也不是墨守成规，也不是发个通知就完事了的。

可以这样吗？我菜鸟额。。

[yuanzhihai]

官方的有些扩展 还依赖框架的 比如 topthink/think-trace topthink/think-multi-app 这些也得自己去fork一份的

[augushong]

不需要，这个是composer的一个特性，如果你只定制了think-framework的几个文件，那么这样写就行：

{
    "repositories": [
        {
            "type": "git",
            "url": "git@gitee.com:ulthon/framework.git"
        }
    ],
}

这里只是举个例子，这样composer会加载ulthon/framework而不是公共仓库里的代码。 你可以试试。

我这里的链接是假的，你换成你自己的fork的版本。

[hulang]

你自己先试试。。

[augushong]

fastadmin就是这么搞的。你可以看一下他的代码，他的composer.json。 composer的文档里也有说明。 你自己有问题有需求，现在有方案，那就立即动手啊。

[hulang]

fastadmin就是这么搞的。你可以看一下他的代码，他的composer.json。 composer的文档里也有说明。 你自己有问题有需求，现在有方案，那就立即动手啊。

那是不是，不能同步更新官方的：top-think/framework了？每次官方更新：framework，我都得更正拉取下？

[augushong]

恩，你直接反向pr就行了。

[yangweijie]

https://gitee.com/pgcao/tp6_vqmod?utm_source=wechat_session&utm_medium=social&utm_oi=27735409819648 这个可以魔改tp 的框架 和扩展 不怕升级