d8dfun/virtual-kubelet
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity
Files
513cebe7b7cf590cd53c02ea8da1a20b58dd8f18
virtual-kubelet/vendor/github.com/vmware/vic/doc/processes/BRANCHING.md
Loc Nguyen 513cebe7b7 VMware vSphere Integrated Containers provider (#206) 
* Add Virtual Kubelet provider for VIC

Initial virtual kubelet provider for VMware VIC.  This provider currently
handles creating and starting of a pod VM via the VIC portlayer and persona
server.  Image store handling via the VIC persona server.  This provider
currently requires the feature/wolfpack branch of VIC.

* Added pod stop and delete.  Also added node capacity.

Added the ability to stop and delete pod VMs via VIC.  Also retrieve
node capacity information from the VCH.

* Cleanup and readme file

Some file clean up and added a Readme.md markdown file for the VIC
provider.

* Cleaned up errors, added function comments, moved operation code

1. Cleaned up error handling.  Set standard for creating errors.
2. Added method prototype comments for all interface functions.
3. Moved PodCreator, PodStarter, PodStopper, and PodDeleter to a new folder.

* Add mocking code and unit tests for podcache, podcreator, and podstarter

Used the unit test framework used in VIC to handle assertions in the provider's
unit test.  Mocking code generated using OSS project mockery, which is compatible
with the testify assertion framework.

* Vendored packages for the VIC provider

Requires feature/wolfpack branch of VIC and a few specific commit sha of
projects used within VIC.

* Implementation of POD Stopper and Deleter unit tests (#4)

* Updated files for initial PR
2018-06-04 15:41:32 -07:00

2.2 KiB
Raw Blame History

VIC Branching

This document is used to define a strategy to enable development and testing of release candidate, patch found issues, while allowing development of future releases by way of branching and tagging.

Requirements

(Not in priority order)

  • To insulate development of future releases from RC / GA testing and development.
    • Allow development of future releases.
    • Avoid breaking RC releases while in testing.

Non requirements

  • Define how to enable development of new features on MASTER or otherwise.
  • Define how to test RC / GA releases.
  • Define criteria for backporting or forward porting of found bugfixes, features, etc.
  • Define release trains for patching GA released builds.
  • Define release criteria for RC

Proposal

We can keep changes isolated from RC / GA testing by way of git branches.

###Branching###

  • Use master for future release work.
  • Use RC branch (releases/MAJOR.MINOR.MACRO) for RC release work.
    • TAG branch for each RC
    • TAG with MACRO++ for each patch.

###Accounting###

  • Targeting
    • Bugs found in RC branch need an issue before merging fix to branch targeted to RC, e.g. targeted/<RC branch name>
    • Ideally patch should be merged to MASTER first if it exists there too.
    • Only if issue is targeted for RC, a different PR with the same issue number for the RC branch.
    • Only close issue after each relevant and targeted release has had a fixed merged to it. We can use targeting to verify this.
  • Bugs found in MASTER or any RC branch need to be tagged, e.g.exists/<branches>
  • The release branch will live as long as our support contract exists on that branch, once support sunsets we can remove the branch
  • The CI system will build all branches within the releases/* naming convention on push or tag event and publish the binary to our public binary location

MASTER -------------------------------------------------->
           \                                 \
           0.7----------------                \
               \              \                \
               TAG 0.7.1   TAG 0.7.2            \
                                                 \
                                                 0.8---->