[ckan-dev] Readthedocs and CKAN documentation versions

Tue May 14 10:53:10 UTC 2013

Sorry I haven't come back to this before.

If we are to create private branches anyway why don't we create the
docs from the release branch, ie  docs.ckan.org/en/release-v2.0 as
private, which will keep updated and create the tag based ones on
release as have been doing until now?
We still can get the release branch regularly built (on release-v*)
and don't change the current urls (ckan-*)

> Related, I don't think the "latest" docs should say a version number
> like v2.1a as they currently do. It should just say "latest development
> version" or something.
Fair enough, should be very easy to do.

Adrià

On 10 May 2013 13:11, Sean Hammond <sean.hammond at okfn.org> wrote:
>> Would mapping the release branches, rather than tags, to RTD docs
>> versions work better? That way, as soon as we branch for a release,
>> the docs for that release appear on RTD. Then all we need to do, is make
>> sure it says "beta" somewhere prominent in the docs, until we decide
>> that the release is final.
>>
>> This would mean URLs to old CKAN 1.x releases would change, they'd now
>> be /en/release-v1.8 instead of /en/ckan-1.8. I think we could get RTD to
>> still build the docs for the ckan-1.8 tag but build them "privately", so
>> ckan-1.8 wouldn't appear in the list of versions at the bottom of the
>> page (only release-v1.8 would) but any links out there to /en/ckan-1.8
>> would still work.
>
> If no one objects to this, I'm going to go ahead and try publicly
> building all the release-v* branches on RTD, and changing all the ckan-*
> tags to being built privately. I'll wait until a week or two after 2.0
> has been released to try this though, to avoid any untimely disruption.
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev