NAME
LCFG::Build::Tool::MicroVersion - LCFG software packaging tool
VERSION
This documentation refers to LCFG::Build::Tool::MicroVersion version 0.5.1
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.
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.