Ticket #2603 (closed defect: fixed)

Opened 7 years ago

Last modified 7 years ago

Adopt next->master->release git branch workflow

Reported by: mjuric Owned by: robyn
Priority: critical Milestone:
Component: TCT Keywords:
Cc: robyn, mjuric, ktl, rhl, smm, rowen, RayPlante, gpdf Blocked By:
Blocking: Project: LSST
Version Number:
How to repeat:

not applicable


Based on the branch/build/release discussion as archived on the 'Notes from SAT discussion on branch/build/release' thread on lsst-data, the following branch workflow is being proposed:

  • master is the integration branch for the current devevelopment cycle. Production runs run off master. After a first successful (released) production, master is branched off to release/xxx (where xxx is the version or a descriptive tag; TBD)
  • next is the integration branch for features supposed to land after the current development cycle (or that are driven by other projects). Once the current development cycle finishes, next will be merged into master.
  • tickets are branched off release/xxx (if they're to fix a bug in release), master if they're related to the current development cycle, and from next otherwise.

At the end of the previous/begining of a new cycle, we'd:

  • branch release/xxx off of master, post production. Collect bug-fixes only here. This is to ensure long-term API stability for external users (e.g., Camera).
  • merge next to master.
  • branch next, for new non-critical work.

Any bugfixes that happen on release/xxx should immediately get merged and/or cherry-picked to master. master may infrequently get merged to next, if features implemented on master become needed by the users of next (but not otherwise).

Change History

comment:1 Changed 7 years ago by robyn

  • Cc mjuric, ktl, rhl, smm, rowen, RayPlante, gpdf added

comment:2 Changed 7 years ago by robyn

The proposal discussion from the thread was continued into the 29 Jan 2013 DC Developer Meeting.

Open discussion:

Jim summarized the original proposal (see the email thread:'Notes from SAT discussion on branch/build/release'), Mario summarized the proposal as it appears in this Ticket.

Perry wondered if it would be possible for the long-term branch to merge frequently with the 'master' branch in order to minimize the divergence. The answer is No, that defeats the purpose of isolating the current development work which is time critical from the longer-term work.

Russell suggested that the 'next' branch should have a name annotation (e.g. 'nextS14') in order to clearly delineate when the next sequential 'next' was forked. Dustin (?) remarked that the 'next' branch maintained a history from git-package genesis - sometimes the 'master' and 'next' branches were the same and sometimes, they diverged.

Mario specified that the ancillary issue, raised in the email thread by Paul and K-T, was deferred until later and is not included within the scope of this TCT policy:

Paul writes:
> A thought: with multiple lines of development proceeding simultaneously, I think it will become much more important to be disciplined about our commits.  Specifically:
> * Each commit introduces a single feature
> * A feature is entirely contained within a single commit
> * No commit should (intentionally) break anything (especially builds and tests within a package)
> * The commit message should have a clear one-line summary, along with a full explanation of the changes (and reference to a ticket if applicable)

KT writes:
I agree, but only after "squashing" before review. We should encourage
any and all commits to a ticket; only when the ticket's work is done
should it be "cleaned up".

The TCT members in attendance: Serge, Mario, Russell, Robyn, voted to support this policy. Mario agreed to setup git to support the 'next' branch and implement its creation.

comment:3 Changed 7 years ago by robyn

  • Status changed from new to closed
  • Resolution set to fixed

See DM/Policy/BranchingPolicies for the official policy statement.

Note: See TracTickets for help on using tickets.