Options: Versions

Allow/re-use any version name

Determines whether existing version names may be re-used. Normally, VA Java does not allow version names to be re-used (e.g., once you have named a version "1.0", you can't name any other edition of the same item "1.0"). There are times, however, when re-using a version name makes sense. One common scenario is the case where you have just versioned a project as "1.0" and discover one more bug to fix. Fixing the bug requires creating a new edition which must be versioned. Ideally, you would like to just re-use the "1.0" name and then purge out the old "1.0". This option allows you to do that.

Warn when renaming versions

Renaming versions only effects the library version name of the selected items. It does not affect JavaDoc @version tags or version fields/methods since changing source code for an existing version is not permitted. In order to change any of the source code for a class or one of its methods, a new edition must be obtained. This option determines whether a warning is displayed when renaming versions while either of the above two options is in effect.

Include version info in Jar file manifest files

VA Java 3.5.3 & Above Only

Normally, the Jar files created by VA Java do not contain any version info concerning the classes, packages and projects used to create the Jar file. If this option is turned on, class, package, project and, optionally, solution edition/version info is added to each manifest entry. If the class/package/project/solution is a version, the version label is shown. If it is an open edition, its time stamp is displayed. The "Solution-Versions" entry will only be present if there are loaded solution editions that ultimately contain the referenced class. If multiple solutions contain the class (as would be the case with nested solutions), this will be a comma-delimitated list. In the example below, the new manifest entries are shown in italic.

Name com.instantiations.guitest.GuiTest1.java

Java-Bean False

Digest-Algorithms SHA MD5

SHA-Digest uLYoNugTKmEfGVmRnV4wMCFWQpQ=

MD5-Digest tFiR4M+s+LgWqJB+GOcJWw==

Class-Version 2.5

Package-Version com.instantiations.guitest 2.5

Project-Version GuiTestProject 2.6

Solution-Versions CcSolutionTest 1.2

Update JavaDoc @version tags for all classes and interfaces

Determines whether @version tags on classes and interfaces are automatically updated when an item is versioned. It works regardless of how you version (e.g., automatic, one name or name each) or at what level you version (e.g., project, package or type). Any type with an @version tag will be updated. Those without @version tags are left alone (which means that you have to add the @version tag yourself to any type that does not have one).

By default, the version number that is used is the version number of the item in the repository. A format option is provided in the case that you want to use a different format for the @version tags (e.g., %V, %D). The format used is similar to the version templates used by the version dialog. The format may consist of any of the template tokens shown below.

Update "static public String version" method/field for all classes

Determines whether "static public String version" methods and fields of classes and interfaces are automatically updated when an item is versioned. It works regardless of how you version (e.g., automatic, one name or name each) or at what level you version (e.g., project, package or type). Any type with an "version" method or field will be updated. Those without "version" methods or fields are left alone (which means that you have to add the "version" method or field yourself to any type that does not have one).

The name of the "version" method or field may be specified ("version" by default). The version number that is used is the version number of the item in the repository. A format option is provided in the case that you want to use a different format (e.g., %V, %D). The format used is similar to the version templates used by the version dialog.

Templates

Allows the developer to specify the scheme used for generating new version names from prior releases. Templates may be composed of any literal text and any of the tokens listed in the Version Components list. If the current date is to be part of the template, the date format may also be specified. The user's initials and the default initial version name may also be set here.