Open Stack

On Fri, Nov 23, 2012 at 5:55 AM, Thierry Carrez <thierry at openstack.org>wrote:

> Monty Taylor wrote:
> > On 11/22/2012 09:44 AM, Mark McLoughlin wrote:
> >> On Tue, 2012-11-13 at 15:19 +0100, Thierry Carrez wrote:
> >>>> Should Oslo library packages be part of the co-ordinated release
> >>>> schedule along with the core services? Or should they follow their
> >>>> own (ad-hoc?) release schedule?
> >>>
> >>> Adding another question: should all oslo libraries share the same
> >>> versioning ? i.e. should oslo.config version be updated when oslo.rpc
> >>> needs to be released ?
> >>
> >> No, it's not required, but I think there's some value in a checkpoint
> >> release of all the libraries in the same family using the same version.
> >> It would just make it easier for folks to understand which versions
> >> belong together, given they will be dependent on each other.
>
> IMHO that would add a lot of versioning constraints for little gain. We
> can describe oslo interdependencies using the same mechanism as other
> libraries.
>
> >>>> Which versions get released to PyPi? Should we have a stable branch
> >>>> of these libraries with stable releases?
> >>>
> >>> That's the crux of the issue. We have two valid models:
> >>>
> >>> 1- Integrated with common release, using common versioning, not using
> >>> PyPI, supporting stable/* branches and stable point releases
> >>>
> >>> 2- Ad-hoc versioning, ignoring the common cycle, using PyPI (which
> makes
> >>> stable point releases look weird)
> >>>
> >>> I'm not sure there is a middle solution. I guess we /could/ support
> >>> stable branches and stable point releases in solution (2), despite
> >>> PyPI's lack of good support for it... but then I'd prefer if those
> >>> stable branches were disconnected from the common release cycle (i.e.
> >>> the stable series would be "1.x" and not "folsom") so that we don't tie
> >>> a lot of different weird version numbers to a given series.
> >
> > Let's assume we'll figure out the PyPI question, even if it looks weird.
> > There are examples of other projects using multiple release streams to
> > pypi we can examine (this has a different consumption usecase than the
> > client libs, so I think my objections to stable releases there doesn't
> > apply here)
>
> There seem to be two options there: just push everything on the same
> PyPI module, or have multiple PyPI modules for each series. I'd say the
> latter looks worse. For the former, I suspect you can specify ">=1.2.1
> <2" as far as dependencies are concerned.
>
> What's missing then is a sane view of the tree of available versions,
> but if we upload the same tarballs to PyPI and Launchpad, we can present
> a series-oriented view of the tree of versions that makes a lot more
> sense. We did not really do that (yet) for client libraries because they
> use a single series, so the gain of also uploading to LP is not as
> obvious. Oh and, I'm slacking and did not write that auto-upload-to-LP
> script to hook into CI yet.
>
> >> Well, to add two more questions:
> >>
> >>    * When do we commit to compatibility around a new API in Oslo? When
> >>      it gets committed, when it gets released or when we release an
> >>      officially "API frozen" version?
> >
> > I vote for when it gets released.
> >
> >>    * How do other OpenStack projects consume Oslo libraries during
> >>      development? e.g. can you put a git URL into pip-requires, or must
> >>      you have a pypi release version there?
> >>
> >> You could say e.g. new APIs are committed to when they're released to
> >> pypi and OpenStack projects can only consume new APIs once they've been
> >> released to pypi.
> >
> > Yes please. We have done cross-project git-url consumption before. It's
> > a nightmare (largely because although the python toolchain tempts us
> > into thinking this will work, it doesn't actually fully work.
> >
> >> But that could result us doing library releases too often, integration
> >> with other projects being too slow or us only realizing we've made
> >> drastic API design mistakes after committing to the new API.
> >
> > Honestly, I think you have a slightly easier time of it than the client
> > lib folks in terms of API commitment - since you know who your consumers
> > are, and you can actually check around to see if anyone is using an old
> > API. It's not too terrible - how about we try it that way for a bit and
> > see if there are actual logistical problems?
>
> That's a lot of questions, let's try to explore options and see how dumb
> they sound...
>
> I can picture one option where we would version oslo libraries
> separately, based on classic major.minor.patch format. We could make
> "stable branches" based off major versions. That would be separate from
> the common development cycles and milestones, even if for planning (and
> summit) reasons you would still talk about "grizzly development
> timeframe", and try to slow down towards the end of the cycle. We can
> push all versions to PyPI and use ">=1.2.1 <2" style to solve the
> dependency specification... and push to Launchpad in parallel to provide
> a sane, series-oriented view of the same deliverables.
>
> How does that sound ?
>

+1

Doug


>
> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121126/1d1d947b/attachment.html>