/ 
LCFG-Build-Tools-0.9.30
River stage zero No dependents
/ LCFG::Build::Tool::MicroVersion

NAME

LCFG::Build::Tool::MicroVersion - LCFG software packaging tool

VERSION

This documentation refers to LCFG::Build::Tool::MicroVersion version 0.9.30

SYNOPSIS

my $tool = LCFG::Build::Tool::MicroVersion->new( dir => '.' );

$tool->execute;

my $tool2 = LCFG::Build::Tool::MicroVersion->new_with_options();

$tool2->execute;

DESCRIPTION

This module provides software release tools for the LCFG build suite.

This tool will increment the smallest part of the project version field and then tag a release of the project in the package version-control repository.

It is possible to check that all changes to files have been committed prior to doing a new release. Prior to actually doing the tagging it is also possible to generate the project log file from the version-control system logs.

More information on the LCFG build tools is available from the website http://www.lcfg.org/doc/buildtools/

ATTRIBUTES

The following attributes are modifiable via the command-line (i.e. via @ARGV) as well as the normal way when the Tool object is created. Unless stated the options take strings as arguments and can be used like --foo=bar. Boolean options can be expressed as either --foo or --no-foo to signify true and false values.

dryrun

A boolean value which indicates whether actions which permanently alter the contents of files should be carried out. The default value is false (0). When running in dry-run mode various you will typically get extra output to the screen showing what would have been done.

quiet

A boolean value which indicates whether the actions should attempt to be quieter. The default value is false (0).

dir

The path of the project directory which contains the software for which you want to create a release. If this is not specified then a default value of the current directory (.) will be used. This directory must already contain the LCFG build metadata file (lcfg.yml) for the software.

logname

The name of the changelog file for this software project (e.g. Changes or ChangeLog). By default the value specified in the LCFG metadata file will be used.

checkcommitted

This is a boolean value which signifies whether the software project should be checked for uncommitted files before a new release is made. By default the value specified in the LCFG metadata file will be used.

genchangelog

This is a boolean value which signifies whether the changelog file for the software project should be generated from the commit logs of the version-control system. By default the value specified in the LCFG metadata file will be used.

store_version

This is a boolean value which controls whether the version string (e.g. 1.2.3) should be stored into a lcfg-build-id.txt file when a new project version is tagged. By default the value specified in the LCFG metadata file will be used.

The following methods are not modifiable by the command-line, they are however directly modifiable via the Tool object if necessary. Typically you will only need to query these attributes, they are automatically created when you need them using values for some of the other command-line attributes.

spec

This is a reference to the current project metadata object, see LCFG::Build::PkgSpec for full details.

vcs

This is a reference to the current version-control object, see LCFG::Build::VCS for full details.

SUBROUTINES/METHODS

execute()

This will increment the smallest part of the version field and then uses the appropriate LCFG::Build::VCS module to tag a new release. This also resets the release field to one. See LCFG::Build::PkgSpec for full details regarding the version field.

It is possible to check that all changes to files have been committed prior to doing a new release. If uncommitted changes are detected then the tool will exit with a code of 1. If you have not asked the tool to be quiet it will also print out the list of uncommitted files.

Prior to actually doing the tagging it is possible to generate the project log file from the version-control system logs.

The tagversion method of the appropriate LCFG::Build::VCS module will be used to actually tag the project source code at the new version.

release($level)

This is the method which actually does the work. It takes one optional parameter which specifies the level of the release, if it is not specified then only the smallest (micro) part of the version field will be incremented. When specifying the level it can be any of 'major', 'minor' or 'micro'. When the smallest part of the version field is incremented the release field is also reset to one. For details of the procedure for updating the other parts of the version field see below.

minorversion()

This is a convenience method which calls the release() method with the level parameter set to 'minor'. As well as incrementing the middle part of the version field the smallest part will be reset to zero and the release field will be reset to one.

majorversion()

This is a convenience method which calls the release() method with the level parameter set to 'major'. As well as incrementing the largest part of the version field the middle and smallest parts will be reset to zero and the release field will be reset to one.

fail($message)

Immediately fails (i.e. dies) and displays the message.

log($message)

Logs the message to the screen if the quiet attribute has not been specified. A message string is prefixed with 'LCFG: ' to help visually separate it from other output.

DEPENDENCIES

This module is Moose powered and uses MooseX::App::Cmd to handle command-line options.

The following modules from the LCFG build tools suite are also required: LCFG::Build::Tool, LCFG::Build::PkgSpec, LCFG::Build::VCS and VCS helper module for your preferred version-control system.

SEE ALSO

LCFG::Build::Tools, LCFG::Build::Skeleton, lcfg-reltool(1)

PLATFORMS

This is the list of platforms on which we have tested this software. We expect this software to work on any Unix-like platform which is supported by Perl.

Fedora12, Fedora13, ScientificLinux5, ScientificLinux6, MacOSX7

BUGS AND LIMITATIONS

There are no known bugs in this application. Please report any problems to bugs@lcfg.org, feedback and patches are also always very welcome.

AUTHOR

Stephen Quinney <squinney@inf.ed.ac.uk>

LICENSE AND COPYRIGHT

Copyright (C) 2008 University of Edinburgh. All rights reserved.

This library is free software; you can redistribute it and/or modify it under the terms of the GPL, version 2 or later.