h guys, as docs are amended for released versions I'd have the branching more fine grained then the code branches i.e. have a branch for 4.3.0 and not for 4.3. These may not differ much but it will be a bit clearer to users and may not be much extra work to maintain.
just EURO 0,02 On Thu, Apr 3, 2014 at 10:26 AM, benoit lair <kurushi4...@gmail.com> wrote: > +1 too for doc release with version number according to code releases > > > 2014-04-03 6:41 GMT+02:00 Radhika Puthiyetath < > radhika.puthiyet...@citrix.com>: > >> +1 doc release with version number that match code releases >> >> -----Original Message----- >> From: Sebastien Goasguen [mailto:run...@gmail.com] >> Sent: Wednesday, April 02, 2014 8:52 PM >> To: dev@cloudstack.apache.org >> Subject: Re: RTD documentations >> >> >> On Apr 2, 2014, at 10:09 AM, Pierre-Luc Dion <pd...@cloudops.com> wrote: >> >> > Hi, >> > >> > I was reviewing how to use RTD for CloudStack documentation and look >> > like we could use git branches to match product and doc version. This >> > way we could provide documentation update while and keep the >> > documentation match the product version. it should also be possible to >> > define the default >> > ("latest") to a specific branch so we could have branches for 4.3, >> > 4.4 and still have the default documentation pointing to 4.3 as the >> latest. >> > >> > Did any one tested that? >> >> you are correct but we have not tested it yet. >> >> We need to discuss how we want to release documentation, i.e. do we make >> formal doc release with version number that match code releases, do we vote >> on the doc releases etc. >> >> But you are right that we can tag a special branch and keep track of the >> releases in RTD. >> >> > >> > RTD support also Tags for documentation versioning but if we want to >> > keep matching doc version and CS version we couldn't perform fixes in >> > the doc without updating the doc version. >> >> Right, and that's an issue we had before. If we make a doc release that >> match the code release then we "abandon" that release and never go back to >> fix it, except in bug fix releases or next major releases. >> >> I have not had time to seat down and think through this, ideas welcome... >> >> >> > >> > >> > Pierre-Luc Dion >> > Architecte de Solution Cloud | Cloud Solutions Architect >> > - - - >> > >> > *CloudOps*420 rue Guy >> > Montréal QC H3J 1S6 >> > www.cloudops.com >> > @CloudOps_ >> >> -- Daan
