trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: February 2012

Re: [trinity-devel] Publishing help files, user guides, etc.

From: Kristopher John Gamrat <chaotickjg@...>
Date: Sat, 18 Feb 2012 19:44:30 -0500
On Saturday 18 February 2012 07:11:13 pm Darrell Anderson wrote:
> To cmake and makefile gurus:
> 
> My plan is that starting with R14 the version number and copyright date of all Trinity documentation (help files, user guides, etc.) will be the same as the software release.
> 
> That way the help files and guides look current rather than look 10 years old. By matching the release date and version, users know which release the documentation belongs and is an indication the documentation is not stagnant with a dumb version number like 0.1.
> 
> I will create two entity variables that all related docbook files will use: release date and release version. Therefore the only place we need to update anything would be the entity file and not every single docbook file (ugh). The entity files are part of the tdelibs package.
> 
> During the build process is there a way to automatically update these entity variables? I could do that in my own build scripts but I prefer a method that is global to any packager.
> 
> How this would work: When a person builds from GIT today and then opens a handbook help file, the date would be today and the release would be R14.0.0 [DEVELOPMENT]. That way all drafts of all documentation show the current date and release number. However, when [DEVELOPMENT] is not part of the version string, that is, with an official release, then the date and release number are always hard-coded to the official release date.
> 
> The release version is embedded in the TDE_VERSION_STRING variable in tdelibs/tdecore/tdeversion.h. I don't know whether the release date is hard-coded anywhere. Possibly when detecting that [DEVELOPMENT] is not part of the TDE_VERSION_STRING string, then the release date becomes the file date stamp of tdeversion.h. I'm just speculating and thinking out loud.
> 
> Is this possible?

We would probably need a few people to make sure that documentation is up-to-date with what is currently in 3.5.13 (for example, was the documentation updated when the TMenu search box was added?), and then to make sure it is still up-to-date with new changes/features from R14 on.

I don't yet know much about git, but would it be possible to have a script built in to the server so that when it comes time to release, and development is copied over to stable branch, your variable is updated in stable only? Also, would there be a way of having Tim's quickbuild set it in the nightly builds?

If that is possible, then packagers who are using development would still have to set it in their own development branch packages, but the stable release and nightlies for Debian/Ubuntu would be already set.

-- 
Kris Gamrat
Ark Linux webmaster
http://www.arklinux.org/

Attachments: