@mattab opened this Issue on January 2nd 2020 Member

Often after we release a new version with 100+ changes, there is one regression or a couple. The regressions may be fixed relatively quickly in Git, but we cut the release only weeks later. So for a few weeks Matomo is partially buggy for some people. This happened recently with this regression: https://github.com/matomo-org/matomo/issues/15200 which we fixed, but the fix is not out yet in a release.

Solution will be to release patch versions faster after a main release.

So the solution is to have a plan and process to consistently release patch versions sooner and faster.

as @tsteur mentioned, we might need to work with branches like next patch release... next minor release branch... or at least some develop and a master branch or something. And depending on the fix release fixes within a few days ideally.

Any thoughts or suggestions?

@diosmosis commented on January 2nd 2020 Member

Here is a proposal:

  • after a release is made, merge as if working towards new minor/major release
  • in N day intervals after a release (eg, every 3 business days), merge any relevant PRs merged to mainline with a "Bug" or "Regression" label into a new branch for the patch version, then release a beta if tests pass
  • after however long we want to wait, release the branch as a new patch
@tsteur commented on January 3rd 2020 Member

That could work. Basically, we want to be able to release a patch release at any time. If there's an important fix / regression fix then we would try to release an RC immediately and say 2 days later a proper patch release unless we know we're fixing another important fix within the next say 2 days. Then we could wait. If another important fix is say 3 days away, we might as well release a new patch release and then a few days another patch release

@diosmosis commented on January 3rd 2020 Member

It could also be done like:

  • if a bug/regression pr is merged, create patch branch and merge, make release candidate
  • if N days have passed without a bug/patch being merged, and no issues with the release, make a patch release. if another bug/regression pr is merged into mainline, merge in to patch branch and make another release candidate, then wait N days.

I was thinking this could eventually be automated to some extent. Though I suppose we'd want to be careful about releasing too many patches?

@tsteur commented on January 3rd 2020 Member

I was thinking this could eventually be automated to some extent. Though I suppose we'd want to be careful about releasing too many patches?

Yes I reckon this would be only for important / critical fixes and pretty much only for important regressions.

@diosmosis commented on January 3rd 2020 Member

If we use branches then this is simple, we can create a release branch whenever needed. We probably don't need this issue...

@tsteur commented on January 6th 2020 Member

I reckon we don't need this issue anymore indeed. We just need to do to it. It's otherwise straight forward to create a new branch if needed where we merge important regressions/fixes into it.

This Issue was closed on January 16th 2020
Powered by GitHub Issue Mirror