Freaking Outlook kinda munged my reply, so I'll keep my replies on top. When I saw "edge", I thought that meant *post* release. Err, I mean what's coming next. I've never read "edge" as being "the current release." So if I'm wrong, and it sounds like i am,you can disregard everything I said. :)
> For either option, edge would be equivalent to latest released work. Even if you make changes on master for cordova-docs, it wouldn't be pushed to edge unless we were doing a docs release and the feature was being released. This is definitely something we need to keep track of. I don't think we have been bitten by this before though and don't imagine it being a big problem with either option and setting default docs to edge. Moving platform docs to platform repos and grabbing them at build time for docs would hopefully prevent this type of situation from arising. > Please, please, please do not do this. > > Why can't the docs simply be updated w/o updating the bits? Is that really > the case? If so, fix *that* bug. > I'm not sure I understand what you mean by above? The reason we are needing to switch docs is because we are not doing cadence releases after 3.6.0. So either we have docs live with no version or we version it along side the CLI. Ex. CLI could be at version 5, cordova-firefox could be at version 3.7.0, cordova-android could be at version 4.2, etc. What would the versions of docs be? > > > ________________________________________ > From: Steven Gill <stevengil...@gmail.com> > Sent: Wednesday, August 20, 2014 3:59 PM > To: dev@cordova.apache.org > Subject: Re: What's Stopping us From Independent Platform Releases > > I still feel it would be a mistake to stop versioning our docs. It would > confuse our users. It is a norm for projects to have docs associated to > specific versions. > > I think docs should be versioned when the cli gets released and > docs.cordova.io should always point to edge. This would address the > splashscreen docs not being live even though the feature has shipped. > > This use case can also handle us introducing breaking changes (ex: android > 4.0) and not have to keep older docs on edge. > > Annotating with "supported in android 3.6.0+" can start looking very ugly > over time if we have lots of annotations all over the place. > > As for previous versions, bugs most likely won't be fixed unless it is > something someone volunteers to do. I don't see much value in updating old > versions of docs. But it is worth still having them available for people > using those versions. > > I'd like to hear what others think about this? > > Both proposals are described at > https://issues.apache.org/jira/browse/CB-7226 >
