Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Release patch versions faster after a main release #15344

Closed
mattab opened this issue Jan 2, 2020 · 6 comments
Closed

Release patch versions faster after a main release #15344

mattab opened this issue Jan 2, 2020 · 6 comments
Labels
not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org. RFC Indicates the issue is a request for comments where the author is looking for feedback.
Milestone
4.0.0

Comments

@mattab
Copy link
Member

mattab commented Jan 2, 2020

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: #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?
@mattab mattab added the RFC Indicates the issue is a request for comments where the author is looking for feedback. label Jan 2, 2020
@mattab mattab added this to the 4.0.0 milestone Jan 2, 2020
@diosmosis
Copy link
Member

diosmosis commented Jan 2, 2020 •
edited

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
Copy link
Member

tsteur commented Jan 3, 2020

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
Copy link
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
Copy link
Member

tsteur commented Jan 3, 2020

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
Copy link
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
Copy link
Member

tsteur commented Jan 6, 2020

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.

@tsteur tsteur closed this as completed Jan 16, 2020
@mattab mattab added the not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org. label Sep 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org. RFC Indicates the issue is a request for comments where the author is looking for feedback.
Projects
None yet
Milestone
4.0.0
Development

No branches or pull requests
3 participants
@diosmosis @tsteur @mattab