Happy with this being the first release

The tagging model will follow the Linux kernel
release tags given that its the more complicated
project we track.
rel-html: infer releases

This adds support to infer releases based on the
major and minor numbers of a release (aka, VERSION,
PATCHLEVEL). This removes the requirements for updating
the configuration file every time a new release is made.
An update to the configuration file is only needed now
when its decided a new release is EOL'd or a new major/minor
number gets added to the release model.

So for example for the Linux kernel we make these changes
to the configuration file for it:

	-rel_html_stable_vers   = 3.7.2
	-                         3.6.11:EOL
	-                         3.5.7:EOL
	-                         3.4.25
	-                         3.3.8:EOL
	-                         3.2.36
	-                         3.0.58
	-                         2.6.34.13
	-                         2.6.32.60
	-rel_html_testing_ver   = 3.8-rc3
	+supported =
	+               3.8
	+               3.7
	+               3.4
	+               3.2
	+               3.0
	+               2.6.34
	+               2.6.32
	+eol =
	+               3.6
	+               3.5
	+               3.3

This is what a releas page looks like for it:

http://drvbp1.linux-foundation.org/~mcgrof/rel-html/linux/

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
6 files changed
tree: 4a21510d294f12152aa7375dc9a967bcec31fffb
  1. html/
  2. projects/
  3. agpl-3.0.txt
  4. CONTRIBUTING
  5. LICENSE
  6. README.md
  7. rel-html.cfg
  8. rel-html.py
README.md

rel-html

rel-html is designed to parse naked index html pages with tarballs on a software project and automatically produce a nice shiny HTML5 release page for you. It takes as input a configuration file, rel-html.cfg, in which you can specify attributes for the release.

Example release page

TODO

  • Figure out how to automatically determine releases from git.

    • If we have many stable releases how should we annotate this via git ?
  • See if we can copy the EOL release into an eol/ directory and moving forward instead of parsing the tags use the directory name to automatically determine other release attributes.