Open Stack

Tripp, Travis S wrote:
> Thanks for the info! We had discussed the release models a couple times in our IRC meeting and we thought that the release cycle with intermediary releases sounded good to us.  One reason is that we actually wanted to be able to release more frequently if needed support deployers and developers interested in moving searchlight into production more quickly. Possibly we would be looking to release whenever we improve an integration with an existing project, support an integration with a new project, enable a new feature, address major bugs, or to address UI integration needs.
> 
> As far as the version number, we feel that we have a good basis for the functionality and API at this point. We’re wanting to start getting deployer feedback and want to be able to make changes needed without getting too hung up on major vs minor version changes. So we’ve voted to go with 0.1.0 to allow us time to solidify based on that with a goal of going to 1.0 by the end of the Mitaka release cycle.
> 
>  
> However, in reading the page you sent below it says the following about common cycle with intermediary releases.
> 
> "This is especially suitable to more stable projects which add a limited set of new features and don’t plan to go through large architectural changes. Getting the latest and greatest out as often as possible, while ensuring stability and upgradeability."
> 
> This description of the release model sounds a bit dissimilar from our ideas above, so is this okay with you that we stay on that release model?

The "intermediary" model requires the project following it to be mature
enough (and the project team following it to be disciplined enough) to
internalize the QA process.

In the "with-milestones" model, you produce development milestones and
release candidates to get the features out early and progressively get
more and more outside testing on proposed artifacts. It's "ok" if a
development milestone is revealed to be unusable: that shows lack of
proper testing coverage, and there is still time to fix things before
the "real" release.

In the "intermediary" model, you deliver fully-usable releases that you
recommend production deployments to upgrade to. There is no alpha, beta
or RC. You directly tag a release. That means you need to be confident
enough in your own testing and testing coverage. Mistakes can still
happen (in which case we rush a subsequent point release) but should
really be exceptional, otherwise nobody will trust your deliverables.

This is why we recommend the "intermediary" model to mature projects and
project teams -- that model requires excellent test coverage and
discipline inside the team to slow down development as you get closer to
a release tag and spend time on testing.

-- 
Thierry Carrez (ttx)