Skip to content

Refinement of development/release process #17

@brevilo

Description

@brevilo

As promised in #13 I'd like to add a few comments and questions regarding the latest revision of the development process that could eventually lead to a more refined process description.

  • BOINC Flow
    • Feature or bugfix branches: why "majority" instead of "all"? What's the rest and why isn't it supposed to be contributed that way?
    • Bugfix branches: how do you apply such a bugfix to multiple release branches in a coherent way that avoids code creep? That of course assumes that there are multiple maintained release branches to begin with. Is that the case? Right now I can't find a definition of how we want to handle release branch maintenance. If there is only and exactly one maintained release branch at any given moment, then we should really simplify things and have bugfix branches based on the release branch to be fixed, not its master/release merge-base which calls for mistakes.
    • Bugfix example: (the previous bullet notwithstanding) it should be clarified here that the bugfix branch must be based on the merge-base of master and the release branch in question, not just "created off of master" as that might lead people to think to just branch off master's HEAD, which would be wrong.
  • Client release process
    • Bugs in release branch: are we willing to release known bugs? What kind of bugs are these? How is the process for determining whether to delay a release (fix the bug) or release with a known bug? Can there ever be any pressure (good reason) to release with known bugs? I presume that the known bug is part of a new feature, otherwise it would just be a bug fix. If that's the case, however, I'd argue that the feature should be reverted and moved to the next release, instead of releasing it with known bugs.
    • Tagging release builds: the documents lacks a description of how release builds get (git) tagged. Topic to cover should include when and how (signed or not?) to do that and how those tagged releases should be used (eg. binaries must always be built from tagged commits only).

Let's open the discussion...

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions