> > > -----Original Message----- > From: Ewan Mellor [mailto:ewan.mel...@eu.citrix.com] > Sent: Friday, August 10, 2012 1:01 PM > To: David Nalley; cloudstack-dev@incubator.apache.org > Subject: RE: [ASFCS40] CloudStack 4.0 release plan > > > -----Original Message----- > > From: David Nalley [mailto:da...@gnsa.us] > > Sent: 10 August 2012 12:56 > > To: cloudstack-dev@incubator.apache.org > > Cc: Ewan Mellor > > Subject: Re: [ASFCS40] CloudStack 4.0 release plan > > > > > > > > The only exception I would make to the "everything in 4.0" rule is > > > for > > documentation. I don't see any value in branching the docs, and I > > want to make sure that we can keep updating the docs at a fast pace > > even as we're deliberately slowing down the rate of change on the > > code. For this reason, I would have all the docs work continue in > > master, so there would be no additional gatekeeping there, just the > > usual review. Is everyone OK with that? > > > > > > > I've read this several times, and not sure that I understand.....Are you > saying: > > that docs will continue to go into both 4.0 and master and will skip > > the gatekeeper? > > or that docs (e.g. the docs that will exist for 4.0) will happen only > > in master going forward? > > > > The latter concerns me, as we will release a source tarball whose docs > > won't match our 4.0 release docs. Presumably master will rapidly move > > on towards > > 4.1 docs after release, and we'll have no demonstrable way to hack on > > 4.0 docs or for downstreams to consume 4.0 docs or for us to produce > > translations of the exact 4.0 docs after they move on. In short my > concern is: > > how do we produce a 'this is the source for docs that match this code > > release', and ensure that that point in time still exists 6 months > > down the road? > > How about we keep working on docs in master, and then dump the latest > snapshot into the release branch before we do the final build? > > Ewan. >
I like this idea. The rate of change in documentation speeds up the closer we get to a release. This makes docs the opposite of code. I'd like to be able to fix doc bugs for any past release, too, then auto-post the update to docs.cloudstack.org under the correct release number. I will add that to the requirements for our automated doc publishing tool (which, by the way, we could use help implementing!) https://cwiki.apache.org/confluence/display/CLOUDSTACK/Functional+Requirements+for+Documentation+Publishing+Tool Jessica T. CloudStack Tech Pubs
