openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #14064
Re: best practices for merging common into specific projects
On Jul 3, 2012, at 5:31 AM, Thierry Carrez <thierry@xxxxxxxxxxxxx> wrote:
> Gabriel Hurley wrote:
>> On a more fundamental level, did I miss some tremendous reason why we have this "merge from common" pattern instead of making OpenStack Common a standard python dependency just like anything else? Especially with the work Monty has recently done on versioning and packaging the client libs from Jenkins, I can't see a reason to keep following this "update common and merge to everything else" pattern at all...
>
> This discussion should probably wait for markmc to come back, since he
> set up most of this framework in the first place. He would certainly
> produce a more compelling rationale than I can :)
>
> IIRC the idea was to have openstack-common APIs "in incubation" until
> some of them are stable enough that we can apply backward compatibility
> for them at the level expected from any other decent Python library.
> When we reach this point, those stable modules would be "out of
> incubation" and released in a real openstack-common library. Unstable
> APIs would stay "in incubation" and still use the merge model.
>
> My understanding is that we are not yet at this point, especially as we
> tweak/enrich openstack-common modules to make them acceptable by all the
> projects...
>
Ideally when we reach that point the libraries will be released as individual components instead of a monolithic shared library, too.
Doug
References