This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Clean up old and obsolete branches protocol
Skip to end of metadata
Go to start of metadata

The goal of this process is to maintain our official repository nice and tidy; thus, helping newcomers to get around our codebase without loose ends. We detail the protocol to be followed either when using the official repository to store a development branch or to remove an obsolete branch that was forgotten in CloudStack's official repository. As long as all of the steps detailed here are followed, anyone can request the removal of an obsolete branch in the official repository. The rules are the following.

  1. We only maintain the master and major release branches. We currently have a system of X.Y.Z.S. I define major release here as a release that changes either ((X or Y) or (X and Y));
  2. We will use tags for versioning. Therefore, all versions we release are tagged accordingly, including minor and security releases;
  3. When releasing the “SNAPSHOT” is removed and the branch of the version is created (if the version is being cut from master). Rule (1) one is applied here; therefore, only major releases will receive branches. Every release must have a tag according to the format X.Y.Z.S. After releasing, we bump the POM of the version to next available SNAPSHOT;
  4. If there's a need to fix an old version, we work on HEAD of corresponding release branch. For instance, if we want to fix something in release 4.1.1.0, we will work on branch 4.1, which will have the POM set to 4.1.2.0-SNAPSHOT;
  5. People should avoid (it is not forbidden though) using the official apache repository to store working branches. If we want to work together on some issues, we can set up a fork and give permission to interested parties (the official repository is restricted to committers). If one uses the official repository, the branch used must be cleaned right after merging;
  6. Branches not following these rules will be removed if they have not received attention (commits) for over 6 (six) months;
  7. Before the removal of a branch in the official repository it is mandatory to create a Jira ticket and send a notification email to CloudStack’s dev mailing list. If there are no objections, the branch can be deleted seven (7) business days after the notification email is sent;
  8. After the branch removal, the Jira ticket must be closed.

In case of doubts or suggestion to change this process, you can reach us at dev@cloudstack.apache.org.

 

 

  • No labels