cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Weingärtner <>
Subject [VOTE] Clean up old and obsolete branches.
Date Tue, 02 Jan 2018 11:46:24 GMT
Hope you guys had great holy days!

Resuming the discussion we started last year in [1]. It is time to vote and
then to push (if the vote is successful) the protocol defined to our wiki.
Later we can start enforcing it.
I will summarize the protocol for branches in the official repository.

   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, we will work on branch 4.1, which will have the POM set to;
   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.

Let’s go to the poll:
(+1) – I want to work using this protocol
(0) – Indifferent to me
(-1) – I prefer the way it is not, without any protocol/guidelines


Rafael Weingärtner

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message