Note: I sent a message to Thierry and Doug for help with the specifics of 
running the release and after Theirry’s response it seemed we should include 
the mailing list.

>Tripp, Travis S wrote:
>>Theirry and Doug,
>>We are down to a single patch that needs one more +2 and then we believe 
>>we’ll be ready to run the first Searchlight RC. We have a core reviewer who 
>>will be done going through it by Monday AM US. Can you please let me know 
>>what will be needed from us to run the release?
>>(note, the BP under code review and bug in progress are both solved in the 
>>same patch).

On 10/5/15, 1:35 AM, "Thierry Carrez" <> wrote:

>Hi Travis,
>Searchlight is currently registered in the governance as following the
>release cycle with intermediary releases (rather than milestones and
>RCs). It is also *not* directly managed by the release team (yet).
>That means you have two options. You can stay with the intermediary
>releases model and just push a tag (1.0.0 or 0.1.0 or...) when you're
>ready for release.
>You can switch to a milestone-based model and do a RC: in which case you
>should push a tag.
>In both cases you should cut a stable/liberty branch from that (we can
>help with that part).
>Then in the milestone-based model case you would re-tag the
>with a 1.0.0 tag as we get nearer to final release day. In the
>intermediary model you would only reissue a tag if you detect an issue
>which warrants a 1.0.1 (or 0.1.1) point release.
>Try first to decide which model you'd like to follow: the one registered
>in the governance (intermediary) or the one with RCs that you seem to
>follow (milestone-based). Those are described in the project team guide:
>Thierry Carrez (ttx)

Hi Thierry,

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 

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?


OpenStack Development Mailing List (not for usage questions)

Reply via email to