[OpenStack-docs] openstackdocstheme and Mitaka release?

Lana Brindley openstack at lanabrindley.com
Wed Mar 16 04:44:32 UTC 2016


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16/03/16 05:47, Andreas Jaeger wrote:
> Currently our guides using openstackdocstheme (and that includes also
> documents like Compute API in the nova repository) hardcode the release
> name and links to releases in them.
> 
> See the attached screenshot for an example or look directly at one of
> the guides like http://docs.openstack.org/admin-guide-cloud/ .
> 
> This already confused some folks since we always build with latest theme
> and thus the kilo guide now will have Liberty in the theme. Also, we
> have guides that are version independent - we call them also continously
> released - like User Guides. These cover the current "supported"
> releases but they have only "Liberty" written on them.
> 
> With each OpenStack release we face the challenge to update the
> openstackdocstheme at the right time. We don't want to do it too early -
> so not have yet Mitaka out - but also not to late - we'd love to be
> ready when Mitaka is out. This puts stress on OpenStack and
> documentation release teams to release this timely - against the normal
> policies setup for releases.
> 
> I chatted earlier today with Doug Hellmann and Dims and we discussed
> some options including the following:
> 
> 1) Leave status quo.
> 2) Enhance openstackdocstheme to have an option that names the release.
> This means we need to add to each of the 10+ repos currently using it
> this option. Advantages are that we could even have different links
> there - for Liberty guides, links to Liberty, for Mitaka ones, links to
> Mitaka,...
> 3) Add the next release links far earlier (now). This will remove
> pressure everywhere but forces us to publish a docs.openstack.org/mitaka
> page as well.
> 4) Remove the version completely, instead point to docs.openstack.org
> top level page. In that case, we should also remove the list of releases
> from the navigation bar.
> 5) Any other options we didn't think about?
> 
> I'm in favor of option 4 since that avoids confusion and avoids last
> minute changes.

+1 to option 4. It's the least maintenance-heavy, and also less confusing for readers.

L

- -- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJW6OSwAAoJELppzVb4+KUyx3AH/iSJGlMh4FbQKv41PLvbIqCY
/Gp9q3Rev6bRNf4WVvS8CQ+vzB9K9ldUkAPKfqwrW6ASFszugdTwj91u6dbR5XxC
25NOGCsNkAs7ejbORWl0XER+bDez4j5iMkqPc6kwzkaWIkcDB12l6evuVpTwXfoq
IbchKEoqMB2vIsQH3aJLjHzNOkPldFDavzISmgzrOAkXdYCaWiCjBm79XYVE1T9t
MjxKwGVOn0ByuuCRepXTJrehJfixSaSBmkZQp7JIiXPQ+2+jCuYIiE+gBq7lVaE4
ouOttsv+qbjYV+dX+WZqHade83p5P9LHP+cQ6rJdzBOVkSb9qgfMYdHG0h7SkbU=
=OwHp
-----END PGP SIGNATURE-----



More information about the OpenStack-docs mailing list