New release system generally

[acoliver]

Until recently, I was really disappointed with Gemini-cli's direction and had thought I'd stop cherrypicking because they kept making the code a bigger mess. While there are still things I'd like to do (modularize) -- their code has gotten a lot cleaner and they're working on some things we really do want. To this effect I'm implementing a new release system:

Odd-numbered releases (i.e., 0.5.0, 0.7.0) are feature releases. We don't do general cherry-picking (though we may do some strategic pickings) and focus on the features we're developing.

Even-numbered releases (i.e., 0.6.0, 0.8.0) are cherry-picking and stability releases. We do general cherry-picking from upstream and also work on general stability. My goal is to cherry-pick 2-3 releases per cycle until we catch up.

With 0.6.0 we are cherrypicked up to gemini-cli 0.9.0. We didn't stick perfectly to the idea in that there are some important new features in this release, but generally it's mostly cherry-picks and stability fixes, and a lot less feature-full than 0.5.0. The next cherry-pick will be 0.8.0, and we'll target cherry-picking to gemini-cli 0.12.0.

You can see what is targetted for each release in the issues system under labels such as "required for 0.6.0".

[e2720pjk]

May I confirm whether the phase between v0.6.0~v0.7.0 is dedicated to new feature development, or should it be regarded as a stability update phase since the version number remains v0.6.0?

[acoliver]

We're working on 0.7.0. I just haven't bumped the version yet. This is a feature release.

[e2720pjk]

Nice~I can send out the feature PR now