To add to what Pierre-Luc said: Readthedocs has something they call "releases" but those are in fact builds that point to a branch. Not a specific tag.
So the release version of the doc we would see on the website will be the live state of the release branch, not a tag that we could vote on. That said, we have not yet discussed whether or not we need to formally vote on doc releases :) -sebastien On Apr 15, 2014, at 3:56 PM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > makes sense! the only behavior that needs to be taken into account is > that of any publication scripts that we might write. So it seems to me > this is the best result we have from this version of the hackathon :( > & :) > > On Tue, Apr 15, 2014 at 2:54 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote: >> At the hackathon of CCCNA14 with Sebastien, we made few tests the RTD for >> documentation versioning. >> >> Look like we can use branch instead of tag for versioning and we can also >> select which branches are published on RTD.org >> >> So, in order to have doc version match product version, would it make sense >> to create a branch call 4.3.0 for the current CS version and start updating >> master for next version 4.4 ? once we will have 4.4 pretty much ready we >> will be able to create new branch 4.4. >> >> By using branches it allow us to update documentation without having to >> update is version. >> >> Make sense? Have we missing a potential GIT behaviour doing it this way? >> >> >> Pierre-Luc Dion >> Architecte de Solution Cloud | Cloud Solutions Architect >> 855-OK-CLOUD (855-652-5683) x1101 >> - - - >> >> *CloudOps*420 rue Guy >> Montréal QC H3J 1S6 >> www.cloudops.com >> @CloudOps_ > > > > -- > Daan
