On Apr 17, 2014, at 5:31 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
> 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. > I think your email here explains it well. What we need now is a [DISCUSS] thread on whether we want to vote on docs releases and whether we need a formal release process or not ? Do you want to start that thread ;) > > > > > 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 >>> >>
