Open Stack

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?
>>https://launchpad.net/searchlight/+milestone/liberty-rc1
>>(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" <thierry at openstack.org> 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 1.0.0.0rc1 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 1.0.0.0rc1
>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:
>
>http://docs.openstack.org/project-team-guide/release-management.html
>
>-- 
>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 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?


Thanks,
Travis