augushong
augushong
或许可以做成扩展，实现一个版本管理器。回头试试。
没有，事多。过段时间有精力了再说吧。
这个就算实现了，也有点偏门，还得看官方的意思。 我的思路就是，把本身对flysystem的使用的方法做个抽象接口，然后做一个对此的composer扩展，比如叫think-flysystem,v1,v2,v3, 每个版本都对应相应的flysystem。 这样应该不影响框架上层的使用。如果需要切换flysystem的版本，先切换think-flysystem的版本就好了。 最近没精力做，而且影响太大，得慎重。最终也得官方出面。
flysystem的v1版本确实有问题，能升级最好。
你这个提交不太可能接受的，这变动相当于开一个6.1的版本了。 如果能做到无缝升级，在经过充分测试，应该还好办。
但是使用了flysystem v1的用户是不能升级的，依赖会冲突的。尤其是一些二开后台，早就集成了很多第三方的存储。
之所以不做这个改动，其实就是因为目前都是基于flysystem 1的生态。这样相当于放弃了
是的，这个方法有点偏门，但是并没有什么问题。 而且框架本身就把很多通用方法独立成扩展了，比如：think-helper。 这样做也比较符合框架的调性。 也不需要很大的决心，毕竟不会影响旧的生态。
哈哈，composer的新版本加上了风险提示。这就更容易推动这样的更新。
主要是贡献者太少了。白嫖的更是减分。难