Documentation versioning

[noirbizarre]

A first proposal to version documentation and to automate release.

I need some more details on the desired scheme for the Changelog.
Now the versions are 3 digits and they appear as 2 digits in the changelog.

Does it mean that new micro versions (third digit increment) should not add entries in the changelog ?

I will take in account any remarks on the topic and update this PR.

[cdunklau]

I don't know how this would be implemented, but I suggest that http://docs.getpelican.com/en/latest/ should point at the current released version, not the dev version. Then perhaps have http://docs.getpelican.com/en/dev/ for the development version?

[saimn]

It is possible in readthedocs admin to tell that http://docs.getpelican.com/ should redirect to a given version (http://docs.getpelican.com/en/3.1.1/ for example).

[noirbizarre]

http://docs.getpelican.com/en/latest/ will always point to the latest build from masterbranch.
As @saimn said, you can redirect http://docs.getpelican.com/ to a given version from the admin interface.

This PR simply ensure that a version released on PyPI is linked to the right documentation.
It display a warning on the development version (by using a .dev suffix when not released)

The release.sh script automate the versionning, releasing and tagging.

I just need the rules used for changelog versionning to complete it.

[saimn]

There is a project which does in python (I didn't test it): https://github.com/peritus/bumpversion

[almet]

This seems very useful, people won't make mistakes thinking they're looking at a released version if they're not.

+1 for using python rather than bash. @noirbizarre maybe you want to have a look at bumpversion?

[justinmayer]

@noirbizarre: If you're available this weekend, join us for the Pelican sprint and perhaps we can discuss this topic in greater detail. (^_^)

[justinmayer]

Hi @noirbizarre. I would like to get your contribution merged prior to releasing Pelican 3.3. To answer your question:

I need some more details on the desired scheme for the Changelog. Now the versions are 3 digits and they appear as 2 digits in the changelog. Does it mean that new micro versions (third digit increment) should not add entries in the changelog?

While we have sometimes omitted changelog entries for minor doc/bug fixes, we should probably include these as well in the changelog. So let's assume that new micro versions (3rd-digit increment) will also add entries in the changelog.

Would you please review your contribution, taking into account the existing comments to this issue thread, and let me know your thoughts regarding how we might proceed? Thanks, Axel!

[noirbizarre]

Hi @justinmayer
I'm sorry for the delay, I wasn't available.

I'm currently porting my script to a standalone python application because neither bump or bumpversion satisfy exactly my needs and workflow.
I'll update my pull request ASAP after the release today or tomorrow

[justinmayer]

Sounds great, Axel. Looking forward to it!

[coveralls]

Coverage remained the same when pulling bad8cfb on noirbizarre:doc-versionning into 1fad70e on getpelican:master.

[coveralls]

Coverage remained the same when pulling bad8cfb on noirbizarre:doc-versionning into 1fad70e on getpelican:master.

[noirbizarre]

I updated my pull-request as requested:

• rebased on master
• replaced the release.sh script by a Bump'R configuration

To perform the 3.3.0 release, it's as simple as:

$ bumpr -m

[justinmayer]

Thanks, Axel! Will take a look at this over the weekend. (^_^)

[coveralls]

Coverage increased (+1.34%) when pulling 5a322ec on noirbizarre:doc-versionning into 1fad70e on getpelican:master.

[justinmayer]

Many thanks, Axel. Looking forward to putting this to good use!