Excerpts from Gauvain Pocentek's message of 2014-09-04 22:29:05 -0700: > Hi, > > A bit of background: I'm working on the publication of the HOT > resources reference on docs.openstack.org. 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/ ). 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?
What we ship in-tree is the standard library for Heat. I think Heat should not tie things to the release of OpenStack, but only to itself. The idea is to simply version the standard library of resources separately even from the language. Added resources and properties would be minor bumps, deprecating or removing anything would be a major bump. Users then just need an API call that allows querying the standard library version. With this scheme, we can provide a gate test that prevents breaking the rules, and automatically generate the docs still. Doing this would sync better with continuous deployers who will be running "Juno" well before there is a "2014.2". Anyway, Heat largely exists to support portability of apps between OpenStack clouds. Many many OpenStack clouds don't run one release, and we don't require them to do so. So tying to the release is, IMO, a poor coice. We do the same thing with HOT's internals, so why not also do the standard library this way? _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev