Open Stack

Le 2014-09-08 17:10, Anne Gentle a écrit :
> On Fri, Sep 5, 2014 at 5:27 AM, Steven Hardy <shardy at redhat.com> 
> wrote:
> 
>> On Fri, Sep 05, 2014 at 03:56:34PM +1000, Angus Salkeld wrote:
>>>     On Fri, Sep 5, 2014 at 3:29 PM, Gauvain Pocentek
>>>     <gauvain.pocentek at objectif-libre.com> wrote:
>>> 
>>>       Hi,
>>> 
>>>       A bit of background: I'm working on the publication of the HOT 
>>> resources
>>>       reference on docs.openstack.org [1]. This book is mostly 
>>> autogenerated from
>>>       the heat source code, using the sphinx XML output. To avoid 
>>> publishing
>>>       several references (one per released version, as is done for 
>>> the
>>>       OpenStack config-reference), I'd like to add information about 
>>> the
>>>       support status of each resource (when they appeared, when 
>>> they've been
>>>       deprecated, and so on).
>>> 
>>>       So the plan is to use the SupportStatus class and its 
>>> `version`
>>>       attribute (see https://review.openstack.org/#/c/116443/ [2] ). 
>>> And the
>>>       question is, what information should the version attribute 
>>> hold?
>>>       Possibilities include the release code name (Icehouse, Juno), 
>>> or the
>>>       release version (2014.1, 2014.2). But this wouldn't be useful 
>>> for users
>>>       of clouds continuously deployed.
>>> 
>>>       From my documenter point of view, using the code name seems 
>>> the right
>>>       option, because it fits with the rest of the documentation.
>>> 
>>>       What do you think would be the best choice from the heat devs 
>>> POV?
>>> 
>>>     IMHO it should match the releases and tags
>>>     (https://github.com/openstack/heat/releases [3]).
>> 
>> +1 this makes sense to me.  Couldn't we have the best of both worlds 
>> by
>> having some logic in the docs generation code which maps the 
>> milestone to
>> the release series, so we can say e.g
>> 
>> "Supported since 2014.2.b3 (Juno)"
> 
> I agree with the matching of releases, but let's set expectations for
> how often it'll be generated. That is to say, each tag is a bit much
> to ask. I think that even each milestone is asking a bit much. How
> about each release and include the final rc tag (2014.2?)

This option looks good to me.

Gauvain


> 
>> This would provide sufficient detail to be useful to both folks 
>> consuming
>> the stable releases and those trunk-chasing via CD?
>> 
>> Steve
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [4]
> 
> 
> 
> Links:
> ------
> [1] http://docs.openstack.org
> [2] https://review.openstack.org/#/c/116443/
> [3] https://github.com/openstack/heat/releases
> [4] 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