Release Policy about wind HOT 4 OPEN

bump!
There was no opinion expressed in this bug, and it is crucial to establish a release policy. I would like to create v1.0-series branch so that I can checrry pick fixed bugs, but I would like to see your opinions first.

from wind.

+1

On Sun, Jan 5, 2014 at 2:53 PM, sque [email protected] wrote:

bump!
There was no opinion expressed in this bug, and it is crucial to establish
a release policy. I would like to create v1.0-series branch so that I can
checrry pick fixed bugs, but I would like to see your opinions first.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/22#issuecomment-31603465
.

from wind.

My thoughts:

Branches

Diverting from "master" always creates a branch in Git. The difference is wether you want the branch publicized, before it becomes ready. The criteria should not be the number of commits or the time it takes to complete a feature, but the quality of the code changes and if they are good enought to get public. This means that the branch should be in a shape where other developers are able to contribute, otherwise publicizing it is useless.

Major&Minor Releases

Master branch should always be the latest and never freeze. We can always tag a release candidate from it and branch if we need to backport some fixes for bugs later discovered. Normally, we could end up for a branch for each minor release. Each of these branches would usually contain backported fixes preparing the next patch release.

from wind.

+1

from wind.