serve-d icon indicating copy to clipboard operation
serve-d copied to clipboard

Speed up the release process

Open aminya opened this issue 4 years ago • 3 comments

Serve-d seems to follow SEMVER, but it doesn't actually do that in reality. The jump from 0.6 to 0.7 has taken more than 500 days.

Semver versioning suggests that you should bump the "minor" version for "each" new feature, but in reality, many features are being added for this small jump. I suggest not using SEMVER for this project. The suitable method seems to be one release every two years.

aminya avatar May 01 '21 10:05 aminya

I agree the releases are slow, but they are following semver still. The minor version bumps are for backwards-compatible changes, but for 0.x.y versions every minor change is like major versions after a 1.0.0 release and may include backwards-incompatible changes.

I'll consider using things like the Projects board on GitHub to better plan releases, however in the past it used to not work so well. Currently for the next release I only planned to finish the testing implementation, however because of both new test provider APIs being implemented in vscode and also new bugs (esp. memory leakage) being introduced by the partial implementation right now I have been holding onto that for a little longer.

WebFreak001 avatar May 01 '21 19:05 WebFreak001

I agree the releases are slow, but they are following semver still. The minor version bumps are for backwards-compatible changes, but for 0.x.y versions every minor change is like major versions after a 1.0.0 release and may include backwards-incompatible changes.

An important part of semver is using "semantic releases". Every commit to the main branch should trigger a new release. But this is not what has happened here.

https://github.com/semantic-release/semantic-release

Using semver without semantic-release is just using a portion of its benefits, and leads to situations where people will just defer bumping the versions altogether.

I'll consider using things like the Projects board on GitHub to better plan releases, however in the past it used to not work so well. Currently for the next release I only planned to finish the testing implementation, however because of both new test provider APIs being implemented in vscode and also new bugs (esp. memory leakage) being introduced by the partial implementation right now I have been holding onto that for a little longer.

We should probably decouple the releases of serve-d from code-d. Many other editors rely on serve-d for their functionality. The bugs in the VsCode should not affect the others.

aminya avatar May 24 '21 23:05 aminya

that's a good point. Do you think fixed monthly releases with deadline would help?

WebFreak001 avatar May 25 '21 10:05 WebFreak001