Code Monkey home page Code Monkey logo

Comments (5)

frouioui avatar frouioui commented on June 10, 2024 1

This proposal sounds good to me, however I have concerns about the 2-weeks period before the RC-1 release. If we want to be able to do bug fixes, I think we might as well release an RC-1 early (at the beginning of the 2 weeks period) and leave enough time for everyone in the community to test the RC-1. Because unless people are running their systems on Vitess' main, we won't get many bug reports from the community.

That would also allow us to not block development on main.

from vitess.

L3o-pold avatar L3o-pold commented on June 10, 2024

Thanks for this @deepthi, you perfectly summarise the "issue" and your proposal match what I was thinking.

Bugs can be introduced into the release branch after an RC which are not caught until GA

it's the main issue IMO

If we fix a bug, we publish another release candidate

exactly 👍

from vitess.

frouioui avatar frouioui commented on June 10, 2024

The latest release candidate commit is used to make the GA release.

Just to be clear here, the exact same commit cannot be used as we have to push more commits during the release process of the GA. However, the release PR of GA will be based on a RC commit.

from vitess.

systay avatar systay commented on June 10, 2024

Once RC1 is published, we accept bug reports against that and evaluate whether they should be fixed. If we fix a bug, we publish another release candidate.

Would we do this immediately after every bug fix, or should we accumulate bug fixes for some time before doing the next RC?

from vitess.

frouioui avatar frouioui commented on June 10, 2024

Would we do this immediately after every bug fix, or should we accumulate bug fixes for some time before doing the next RC?

I agree with @systay. But, doing a RC takes some time and some planning, it will be time consuming for the release team to do a new RC after each bug fix or even every other day. I think we need some sort of cadance/schedule, just an example: one or two RC per week (if needed: when there are new bug fixes). That way the release team knows what to expect during the period between the first RC and the GA release, and a day before every scheduled RC they can evaluate if a new RC is really needed.

from vitess.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.