Boris Pavlovic wrote: > The main idea is next: > *) Master branch will be used for new major Rally versions development > e.g. 0.x.y -> 0.x+1.0 switch > that can include not backward compatible changes.
You mean x.y.0 -> x+1.0.0, right ? > *) Latest version - we will port plugins, bug fixes and part of features > to it > *) Stable version - we will port only high & critical bug fixes if it is > possible So... this is pretty close from what we're doing elsewhere in OpenStack, except that we do: Feature branches: not backward compatible changes Master: bug fixes, backward-compatible features, release regularly Stable: High/Critical bugfixes backports, release on-demand The only difference with your model is how you split feature development between master and feature branches. In your model you do most of the feature development in the experimental branch (master) and port pieces of it in the release branch (latest). In our case only the backward-incompatible work lands in the experimental branch (feature/*), and the release branch (master) contains everything else. I am just not sure it's different enough to justify being different :) -- Thierry Carrez (ttx) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev