at this point do we have to create a new [discuss] thread? I'm still not familiar with Apache process so I can start a new thread.
I would also add few consideration. by using branches, let say we create a branch 4.3 for current CS version, this branch would be the default visible on RTD and we wouldn't see latest anymore, the master branch would be the work in progress for version 4.4 of CS. although, if we have a need for 4.3.1, then we would have to create a branch 4.3.1 and update doc so it reflect new fixes, instructions,.... master and 4.3.1 branch would not be visible on RTD until the CS version is released, but branches would be available on the GIT repo. This way, we can work on the release-note documentation as the CS version is under development, this RN is not visible from RTD because the CS version is not released but it is available in the gitrepo as master branch or sub version branch. So on RTD we would only see RN of Released version of CloudStack. if typo or upgrade notes have to be corrected on RN of release CloudStack Version, those fix would have to be performed on the branch directly and the branch would have to be rebuild in RTD, this would not change the documentation version show on RTD. I guest this working method need a vote? at lease a [discuss] ? but if someone need fixes in RN, example: fix typo, this wouldn't require vote right? 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 Thu, Apr 17, 2014 at 12:03 PM, sebgoa <run...@gmail.com> wrote: > > On Apr 17, 2014, at 5:57 PM, David Nalley <da...@gnsa.us> wrote: > > > Are you shipping (e.g. making source available for download) tarballs > > or merely producing documentation that we publish publicly. > > If the answer to that is no; then we don't need votes or a formal > > release process (anymore than we need votes for publishing content to > > cloudstack.apache.org > > -sources are available through the asf git repo and the github mirror. > -we do not make docs tar ball or packages. > -we do build pdf and potentially epub that people can download > > As a matter of fact since the build and publishing platform is external to > ASF infra, we (I since it's my RTD account) are just consuming the docs > from git and providing it to the community like we do with .debs and .rpms . > > Good point David, > > > > > --David > > > > On Thu, Apr 17, 2014 at 11:43 AM, sebgoa <run...@gmail.com> wrote: > >> > >> 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 > >>>>> > >>>> > >> > >
