choose minor version update strategy

[hardfist]

We batched quite a lot of breaking changes in the 0.4 version, which might make it difficult for some users to upgrade. Therefore, we want to conduct a survey to find out which upgrade strategy is more user-friendly.

• Infrequent releases (expected one minor version every two months): Each minor version might contain multiple breaking changes (you can switch to old compatible behavior based on feature gates)
• Frequent releases: A minor version is released promptly when there’s a need for a breaking change, which might result in more frequent minor version releases.

[yanhaijing]

我感觉在1.0之前可以频繁发布，等发布了1.0 改成2个月发布，现在应该是尽快发布1.0，先别考虑这个问题

[hardfist]

这里说的是包含breaking change的版本发布策略，1.0之后应该会一年甚至两年后才会发布下一个breaking change版本

[yanhaijing]

语义化版本，在1.0之前，0.y.z y版本的更新就可以是breaking change，所以让使用者自己小心吧

[yanhaijing]

所以你们快点出1.0，现在这样用着，我很忐忑，ಥ_ಥ

[daydayhappychao]

我选频繁更新 minor
把 break change 带来的风险交给用户在手动升级版本时通过阅读 changelog 去判断，而不是有了新功能但无法通过 release 使用。。
话说这个问题的本质就是你们对包的 major minor patch 版本的定义吧

[hardfist]

我们是按照semver的版本定义，因为在0.x版本，minor版本就是对应breaking change的版本

[noshower]

1.0 前发布频繁点就频繁点呗，你敢发布，我就敢升级。只要文档写清楚就行。每个 break change 都有清晰的文档说明，以及注意事项，我想大家都愿意升级。

[dreamerldq]

我选择不频繁更新，目前正在使用的人，应该都盼望着1.0早点发布，本质还是希望rspack能够趋于稳定。即便是前期，频繁发布小版本break change也会给用户带来一种不够稳定的感觉。而且之前3个版本更新频率都不高，大家已经习惯了这样一个节奏，突然频繁更新，可能会增加用户的心智负担，需要频繁的去判断是否要跟进更新。