Open Stack

oslo-version fix:
 https://review.openstack.org/17249

cinderclient:
 https://review.openstack.org/17250
 https://review.openstack.org/17251


On 11/30/2012 02:12 PM, Joshua Harlow wrote:
> Completely agree with u, I've been thorough the package nightmare…
> 
> Maybe we can finally fix the whole thing with some consensus now that
> many people have been through the pain.
> 
> From: Matt Joyce <matt.joyce at cloudscaling.com
> <mailto:matt.joyce at cloudscaling.com>>
> Reply-To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
> Date: Friday, November 30, 2012 1:24 PM
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
> Subject: Re: [openstack-dev] [oslo] Oslo library versioning
> 
> 
> Maybe this isn't super helpful, but it has to be said.
> 
> I've been doing some packaging work for openstack lately.  And, that's
> lead to me getting a bit testy on IRC.  Sorry for that.
> 
> A big part of my frustration comes from the way we version inside of
> OpenStack core.
> 
> I'll break this down to two different concerns.
> 
> 
> 1.  First Concern - No standard.
> 
> We are ostensibly doing milestones for components, and independent yet
> standardized versioning for clients.
> 
> Except for swift which is just kind of doing it's own thing not being a
> part of OpenStack at all.
> 
> Now we're discussing possibly introducing a fourth versioning scheme.
> 
> It makes the automation of packaging that much more difficult if I have
> to come up with new logic for every single component of openstack that
> has a different versioning scheme.
> 
> Which leads me to the second point.
> 
> 2.  Second Concern - .git derives our versioning
> 
> First, thank god for the versioninfo file.  Without it, cinderclient
> would be unbuildable in certain situations.
> 
> It boils down to this logic:
> 
> from cinderclient/openstack/common/setup.py  ( which btw is common
> SOLELY to cinderclient every other client does this logic in a different
> yet standard fashion ).
> 
> def get_post_version(projectname):
>     """Return a version which is equal to the tag that's on the current
>     revision if there is one, or tag plus number of additional revisions
>     if the current revision has no tag."""
> 
>     if os.path.isdir('.git'):
>         version = _get_git_post_version()
>         write_versioninfo(projectname, version)
>         return version
>     return open(os.path.join(projectname, 'versioninfo'),
> 'r').read().strip()
> 
> This basically says either grab the version from .git, or the
> versioninfo file.  Except that generating the versioninfo file requires
> .git.
> 
> So I end up having to write logic to figure out release tagging and plug
> in versioninfo files into the clients.  Which would be fine except right
> now we have 3 different approaches to tagging repos in the project.
> 
> Please for the love of all that is happy and free in the world, don't
> create a fourth.
> 
> -Matt
> 
> 
> Hope this doesn't come off as aggressive or angry it's more exasperation. 
> 
> On Fri, Nov 30, 2012 at 11:29 AM, Monty Taylor <mordred at inaugust.com
> <mailto:mordred at inaugust.com>> wrote:
> 
>     Actually, if we have some snapshot releases which look like this:
> 
>     2012.2~G2~5 (for instance)
> 
>     That get turned in to python versions that look like this:
> 
>     2012.2-alpha2.5  (for instance)
> 
>     Then I don't understand why we couldn't upload snapshots and real
>     releases to pypi - and then have nova do:
> 
>     oslo-foo>=2012.2,<=2013.1
> 
>     In its pip-requires.
> 
>     (we might be splitting hairs on this one)
> 
>     On 11/30/2012 11:07 AM, Joshua Harlow wrote:
>     > Is there a versioning scheme that can be followed here?
>     >
>     > Stable releases on pypi have even numbers, odd numbers are unstable?
>     >
>     > Isn't something like that pretty common (?), then u can just upload
>     > everything to pypi.
>     >
>     > Maybe that¹s another idea.
>     >
>     > On 11/30/12 5:45 AM, "Mark McLoughlin" <markmc at redhat.com <mailto:markmc at redhat.com>> wrote:
>     >
>     >> On Mon, 2012-11-26 at 22:40 +0000, Mark McLoughlin wrote:
>     >>> On Fri, 2012-11-23 at 11:55 +0100, Thierry Carrez wrote:
>     >>>> 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.
>     >>>
>     >>> I don't really buy that unstable development releases of Oslo have to go
>     >>> to PyPI in order for core projects to be able to consume them.
>     >>>
>     >>> pip supports http:// URLs of tarballs. Why not use that during
>     >>> development?
>     >>
>     >> I'm kinda waiting for opinions on this :-)
>     >>
>     >> Cheers,
>     >> Mark.
>     >>
>     >>
>     >> _______________________________________________
>     >> OpenStack-dev mailing list
>     >> OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
>     >
>     > _______________________________________________
>     > OpenStack-dev mailing list
>     > OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
> 
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>