Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Release Process

  1. Branch Cutting

                  - Project decides what will make it into the release branch.  This should not include new features but only bug/security fixes.  All new commits should be merged into master first and then we will cherry pick bug/security fixes.  This is "Code Freeze" .  It can happen some time after a release branch is but but makes sense to decided when to do the freeze and cut that branch at that time to minimize what we have to pick into the release branch.

        1.   At some point before an official artifact release (at least 2 weeks).  A release branch will be created off of the master branch.
        2.  The master branch version will be rev'd to the desired version of a future release.
        3.  Only bug and security fixes can now make it into the release branch unless truly exceptional.
        4.  Jenkins jobs will be instantiated for the release branch.
      1. Official Release
        1.  A leading representative from a particular project will initiate the release by doing the following:
          1. Email helpdesk@edgexfoundry.org with the following information:
            1. Link to Jenkins staging job that produced artifact to be released
            2. Type of artifacts to be released (jar, go bin, container)
        2.  The EdgeX Release Engineer will release artifacts as requested and git tag the repository found at the sha checked out in the aformentioned Jenkins staging job.
        3.  RE will push the tag to https://github.com/edgexfoundry/$PROJECT_NAME
        4.  Project representation will PATCH bump the version of the project in the release branch in prep for next patch.

                            - Lock down permissions on the release branch to those who we wish to grant "Release Permissions".  

            2.  Generate or update named release manifest

      ...