feature requests

openhub statistics

authors blog

min. rubyver


If you're reading this on Github, please keep in mind, that this is just a mirror. The development happens on:


publican_creators are a small tool for daily DocBook writers who are using the Redhat publican tool publican_creators asks after launching which title, type and environment should be used. Then it starts publican with that settings and works then with the produced files. It will work on the Article_Info.xml, Book_Info.xml, TITLE.ent, Author_Group.xml and Revision_History.xml and will replace the default values with your name, your company, your company_divison and your private or your business email address, depending on your chosen environment. Also, you can set your config file that you want to remove the Title Logo or the Legal Notice. As a feature, it ships a build script for each project.

The History.rdoc contains a detailed description of what has changed. For most users the NEWS file might be a better place to look since it contains change summaries between the different versions.

hoe-reek is released under the GPL3 License, see the file 'License.rdoc' for more information.

The official website is:


  • GUI to control publican

See the status of the app.


$ publican_creators.rb (Main program)
$ revision_creator.rb (The revision updater)

Or just use the Launcher.

Read the documentation:

This Gem was programmed and tested on Linux systems. If anyone would like to make the methods also fit for other OS, I'm happy about Pull requests.


  • nokogiri

  • parseconfig

  • rainbow

  • notifier

REQUIREMENTS (hard dependencies):

  • yad

  • publican (a 4.x version is needed)


The installation is very easy.

gem install publican_creators
cd /path/to/gem (In case of using RVM ~/.rvm/gems/ruby-$RUBYVERSION/gems/publican_creators)

Read the documentation:

You have to run the setup after each gem update.


After checking out the source, run:

$ rake newb

This task will install any missing dependencies, run the tests/specs, and generate the RDoc.



  • Open a bug report on

  • Please use the -u flag when generating the patch as it makes the patch more readable.

  • Write a good explanation of what the patch does.

  • It is better to use git format-patch command: git format-patch HEAD^


As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.

We are committed to making participation in this project a harassment-free experience for everyone, regardless of the level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, age, or religion.

Examples of unacceptable behavior by participants include the use of sexual language or imagery, derogatory comments or personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct.

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned with this Code of Conduct. Project maintainers who do not follow the Code of Conduct may be removed from the project team.

Instances of abusive, harassing or otherwise unacceptable behavior may be reported by opening an issue or contacting one or more of the project maintainers.

This Code of Conduct is adapted from the Contributor Covenant, version 1.0.0, available at


I'm following the Semantic Versioning for its releases: (Major).(Minor).(Patch).

* Major version: Whenever there is something significant or any backward
  incompatible changes.
* Minor version: When new, backward compatible functionality is introduced a
  minor feature is introduced, or when a set of smaller features is rolled out.
* Patch number: When backward compatible bug fixes are introduced that fix
  incorrect behavior.
* The current stable release will receive security patches and bug fixes
  (eg. 5.0 -> 5.0.1).
* Feature releases will mark the next supported stable release where the minor
  version is increased numerically by increments of one (eg. 5.0 -> 5.1).

I encourage everyone to run the latest stable release to ensure that you can easily upgrade to the most secure and feature-rich experience. In order to make sure you can easily run the most recent stable release, we are working hard to keep the update process simple and reliable.



`master` BRANCH:

The master branch is the current edge of development.


The X.X branch is the last stable branch. It will be used for tarballs.


If you want to merge your branch with the trunk, join the team.

Please base all Merge requests off the `master` branch. Merges to `X.X` only occur through the `master` branch.


Bugs should be reported to You will need to create an account for yourself.