Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <8601580.168391287172412942.JavaMail.jira@thor>
Date: Fri, 15 Oct 2010 15:53:32 -0400 (EDT)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-4851) Parameterize documentation sources so
 that release-time variables (like copyright year and release id) can be
 plugged in when we build a release
In-Reply-To: <21668250.146461287080316762.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Hillegas updated DERBY-4851:
---------------------------------

    Attachment: derby-4851-03-aa-longReleaseID-and-subversionRevision.diff

Attaching derby-4851-03-aa-longReleaseID-and-subversionRevision.diff. This patch parameterizes various strings which appear in our tools and log examples: long Derby release ids (e.g., 10.7.1.0), subversion revision numbers, and year stamps. Committed at subversion revision 1023088.

I am not sure that this is the final word on how we want to keep these examples evergreen. Probably a better solution would be to write a program which generates fresh output for each release and then blends the output into the appropriate dita files. That's more than I want to do today.

It can be objected that the resulting timestamps are odder than the old ones: now timestamps may be several months ahead of when the release was generated, instead of just a few weeks.

The subversion revision stamps will be correct now, though. They are wrong in all previous versions of the docs.

This patch introduces the following new ant variables which can be customized in docs.properties:

release.id.long
subversion.revision

These new ant variables correspond to the following ant tokens which now appear in the docs source:

@RELEASE_ID_LONG@
@SUBVERSION_REVISION@

I re-used copyright.year (@COPYRIGHT_YEAR@) to parameterize the year stamps.


Touches the following files:

-------------

M      docs.properties
M      src/tools/rtoolssysinfo1002629.dita
M      src/devguide/cdevdvlp27715.dita
M      src/devguide/tdevdvlp20349.dita
M      src/getstart/twwdactivity1.dita
M      src/getstart/twwdactivity3_Setup.dita
M      src/getstart/twwdactivity2.dita
M      src/getstart/twwdactivity4.dita
M      build.xml


> Parameterize documentation sources so that release-time variables (like copyright year and release id) can be plugged in when we build a release
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-4851
>                 URL: https://issues.apache.org/jira/browse/DERBY-4851
>             Project: Derby
>          Issue Type: Improvement
>          Components: Documentation
>            Reporter: Rick Hillegas
>            Assignee: Rick Hillegas
>         Attachments: derby-4851-01-aa-copyrightYear.diff, derby-4851-02-aa-shortVersionNumber.diff, derby-4851-03-aa-longReleaseID-and-subversionRevision.diff
>
>
> Right now there are a number of strings which have to be updated in the user guides every time that we cut a branch or generate a release candidate. We should parameterize these strings so that the build script can fill them in. Probably we will have to use the ant substitution task for this because there is no obvious way to do this via DITA.
> These are the variables I am aware of. Please let me know if there are others:
> Latest copyright year (currently 2010)
> 2 part version number (e.g., 10.7) (this is plugged into the ij script output, among other uses)
> 4 part version number (e.g. 10.7.1.0)
> subversion revision number (e.g. 1000400)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.