Open Stack

On 11/27/2012 08:45 AM, Mark McLoughlin wrote:
> On Tue, 2012-11-27 at 08:21 -0800, Monty Taylor wrote:
>> I think it's important to think about what it means to have  6-month
>> lead time between landing a feature in oslo and it being able to be
>> used in any of the projects. So I agree that other projects should
>> only consume new oslo apis if they've been released, and I agree about
>> not publishing dev versions to PyPI - I would counsel against setting
>> them on the hard-and-fast rule of the 6-month core project release
>> cycle. 
>> (obviously, you can always NOT release something if it's not ready) 
> 
> Wait, wait - you misunderstood me.
> 
> Oslo libraries would have a 6 month development cycle. At the end of the
> 6 months, Oslo libraries would be released as part of the co-ordinated
> OpenStack release and also pushed to PyPI. Similarly, releases from the
> stable branch of Oslo libraries would be released along with other core
> project stable releases.
> 
> During the 6 months of development, we'd do regular snapshot releases of
> the libraries and the development branches of core OpenStack projects
> would be able to consume those releases. A snapshot release would just
> be our way of communicating with other core projects that new APIs are
> ready for consumption.
> 
> OpenStack milestone releases would include the latest snapshot releases
> of Oslo libraries. Within a milestone, we have the opportunity to fixup
> API design issues with incompatible changes between snapshots.

Yup. totally misunderstood you.

> The logistics question is about how to make snapshot releases available
> and allow core projects consume them.
> 
> During development, would there be any issue with just using tarball
> URLs in pip-requires? e.g.
> 
>   https://launchpad.net/oslo-config/grizzly/grizzly-2.4/+download/oslo-config-2012.2~g2.4.tar.gz

Yeah - that's fine - except we should use tarballs.o.o - but sure.

> Leading up to final release time, we'd publish the Oslo library releases
> early to PyPI and update pip-requires to use:
> 
>   oslo-config>=2012.2
> 
> The thing is, we don't want to publish dev versions of Oslo to PyPI but
> we *do* want the dev branches of other core projects to be able to use
> dev versions of Oslo.

In general I'm fine with this. In practice, we may need to figure out a
way to indicate "this is a snaphot release" vs. "this is a tagged
release" - but that's an impl detail we can take offline. (I have a
thought, I but I want to bring up a different thing first out of band)

Let's consider this general approach as good and the thing we will work
on engineering for.