[openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?
graham.hayes at hpe.com
Thu Jan 28 19:31:40 UTC 2016
On 28/01/2016 19:13, Mike Bayer wrote:
> On 01/28/2016 01:52 PM, Doug Hellmann wrote:
>> Excerpts from Hayes, Graham's message of 2016-01-28 17:01:09 +0000:
>>> The steps I had looked at doing was this:
>>> 1. Allow a "validate" flag on the Field __init__() defaulting to False.
>>> 1.1. This would allow current projects to continue as is, and projects
>>> starting for the first time to do the right thing.
>>> 2. Deprecate the default value - issue a FutureWarning that it is
>>> changing to True
>>> 3. Deprecate the option entirely.
>>> 4. Remove the option, and always validate.
>>> 3 & 4 are even optional if some projects want to keep using UUIDFields
>>> like StringFields.
>>> Currently the -2 still stands as the reviewer does not like the idea of
>>> a flag.
>>> What are the options for this now? If we are supposed to support all
>>> stable branches of all projects, this is the only option if it is going
>>> to merge in the next 2 years.
>>> Or we can create a ActuallyValidatingUUIDField?
>> I like the idea of adding a new class, though maybe not the name
>> you've proposed here. Projects that want enforcement could use that
>> instead of the UUIDField. Then, as we're able to "fix" UUIDs in
>> other projects, the existing UUIDField class can be deprecated in
>> favor of the new one.
> I'm +1 on a new class, -1 on consuming projects implementing this
> themselves (e.g. more cut-and-paste of key functionality). Normally
> I'd be +1 on the "validates=True" flag approach as well but that makes
> it impossible to ever change the default to True someday. Better to
> deprecate UUIDField in favor of a new class.
I actually ended up writing this
to allow us to deprecate the default value in the future.
>>> 0 -
>>> 1 - https://review.openstack.org/#/c/250493/
>>> 2 -
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev