<div dir="ltr">Hi stackers,<div><br></div><div>As far as you probably know Rally is using independent release model. </div><div><br></div><div>We are doing this to do releases as fast as possible. </div><div>Our goal is to have release at least 1 times per 2 week. <br></div><div><br></div><div>The major reason why we have to have separated release model is that we should ship plugins as soon as possible and plugins are in the same repo with tool, framework and docs. </div><div><br></div><div>Previous model was quite simple, we were planing changes for next release, reviewing and merging those changes and cutting new versions. </div><div><br></div><div>This model worked well until we started doing things that are not fully backward compatible and requires migrations. </div><div><br></div><div>Like 0.1.0 release will take us more then 100 days, which is terrible long for people who is waiting new plugins. </div><div><br></div><div>I would like to propose the new release model that will allow us to do 2 things: </div><div>* Do the regular, fast releases with new plugins </div><div>* Have a months for developing new features and changes that are not fully backward compatible</div><div><br></div><div>The main idea is next: </div><div>*) Master branch will be used for new major Rally versions development e.g. 0.x.y -> 0.x+1.0 switch</div><div>   that can include not backward compatible changes. </div><div>*) Latest version - we will port plugins, bug fixes and part of features to it</div><div><div>*) Stable version - we will port only high & critical bug fixes if it is possible </div><div><br></div><div>Here is the diagram that explains the release cycle: </div></div><div><br></div><div><img src="cid:ii_14fee99e1083cbb8" alt="Inline image 1" width="544" height="249"><br></div><div><br></div><div>Thoughts? </div><div><br></div><div><div>Best regards, </div><div>Boris Pavlovic </div></div></div>