Should we have a page on wiki explaining how we would handle release-notes on RTD ? and then vote on the method? I'm not seeing other alternative to branches exept having one RTD project for each release-notes.
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_ On Tue, Apr 15, 2014 at 12:28 PM, David Nalley <da...@gnsa.us> wrote: > So I think it makes sense for most documents to point to feature > version (e.g. 4.3 branch, 4.4 branch.) E.g. docs for 4.3.1 should be > materially the same as 4.3.0 from a docs standpoint. Release notes are > the exception here, though perhaps they could be dealt with in an > additive way. > > --David > > On Tue, Apr 15, 2014 at 11:17 AM, sebgoa <run...@gmail.com> wrote: > > 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 > > >
