Excerpts from Ronald Bradford's message of 2016-03-03 09:54:16 -0500: > > > * When an option is changed, or marked as deprecated, during normal > > reviews > > > it should then be identified accordingly with these new attributes. > > > * The "changed" attribute would only be applicable moving forward with a > > > developer change in default value, ranges etc (changing help text or > > > re-ordering is not a change). > > > > Would "changed" hold a list of changes, to provide a history? Or would > > it just describe the difference since the last release? > > > > > I would consider "changed" as last release the option has changed, so that > effectively for a given current release did the option change in that > release, or not. An option could change in multiple releases, and would be > indicated as such during each release cycle. > > I do not see this feature providing specifics such as "Option X changed > default value from False to True". It would be that in a section "Changed > Options" there is a list of options marked as changed. The use of comparing > generated configuration files between releases as used now would determine > specifics. The goal here is to narrow down the time to do the work across > many projects and projects with many options.
I see, so we would need to either update the flag at the start of each cycle, or use a release version number and then the config generator could compare the two versions and emit something different when the values are the same? Doug > > > > * Any new options get the "released" attribute. > > > > And that would be set to the version in which the new attribute was > > added? Maybe "added_in" is a better name? > > > > Yes, added or first_added is a better name. > > > > * Initial work to fill in the "deprecated" and "removal" information > > (i.e. > > > for a small number of existing options per project) would add strong > > value > > > to generated documentation. > > > > Amen. > > > > Doug > > > > > * Additional work to add the initial "released" information can be left > > to > > > an intro contributor task. Information of an options existence in a > > > project can be automated via analysis of branches to provide details of > > the > > > seed info needed. > > > > > > As for implementation, the use of a named tuple attribute for > > > oslo_config.cfg.Opt [1] is one approach. Determining how to take > > advantage > > > of debtcollector and versionutils should be considered. > > > > > > [1] > > > > > http://git.openstack.org/cgit/openstack/oslo.config/tree/oslo_config/cfg.py#n636 > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
