IntenseWebs/freeipa
3
0
Fork 0
mirror of https://salsa.debian.org/freeipa-team/freeipa.git synced 2024-12-24 16:10:02 -06:00
Code Issues Packages Projects Releases Wiki Activity
cbb3bfae23
freeipa/VERSION

83 lines
4.0 KiB
Plaintext
Raw Normal View History

Redo the way versioning works in freeIPA. The file VERSION is now the sole-source of versioning. The generated .spec files will been removed in the maintainer-clean targets and have been removed from the repository. By default a GIT build is done. To do a non-GIT build do: $ make TARGET IPA_VERSION_IS_GIT_SNAPSHOT=no When updating the version you can run this to regenerate the version: $ make version-update The version can be determined in Python by using ipaserver.version.VERSION
2008-04-30 16:49:52 -05:00
########################################################
# freeIPA Version #
# #
# freeIPA versions are as follows #
# 1.0.x New production series #
# 1.0.x{pre,rc}y Preview/Testing & RC #
# 1.0.0GITabcdefg Build from GIT #
# #
########################################################
########################################################
# This are the main version numbers #
# #
# <MAJOR>.<MINOR>.<RELEASE> #
# #
# e.g. IPA_VERSION_MAJOR=1 #
# IPA_VERSION_MINOR=0 #
# IPA_VERSION_RELEASE=0 #
# -> "1.0.0" #
########################################################
Become IPA v2 beta 1 (2.0.0.pre1)
2010-12-22 13:36:37 -06:00
IPA_VERSION_MAJOR=2
Set VERSION to 2.99.0 on the 3.0 development branch
2011-08-18 15:59:20 -05:00
IPA_VERSION_MINOR=99
Become IPA 2.1.0
2011-08-14 23:34:48 -05:00
IPA_VERSION_RELEASE=0
Redo the way versioning works in freeIPA. The file VERSION is now the sole-source of versioning. The generated .spec files will been removed in the maintainer-clean targets and have been removed from the repository. By default a GIT build is done. To do a non-GIT build do: $ make TARGET IPA_VERSION_IS_GIT_SNAPSHOT=no When updating the version you can run this to regenerate the version: $ make version-update The version can be determined in Python by using ipaserver.version.VERSION
2008-04-30 16:49:52 -05:00
########################################################
# For 'pre' releases the version will be #
# #
# <MAJOR>.<MINOR>.<RELEASE>pre<PRE_RELEASE> #
# #
# e.g. IPA_VERSION_PRE_RELEASE=1 #
# -> "1.0.0pre1" #
########################################################
Become IPA v2 RC 1 (2.0.0.rc1)
2011-02-14 19:12:05 -06:00
IPA_VERSION_PRE_RELEASE=
Redo the way versioning works in freeIPA. The file VERSION is now the sole-source of versioning. The generated .spec files will been removed in the maintainer-clean targets and have been removed from the repository. By default a GIT build is done. To do a non-GIT build do: $ make TARGET IPA_VERSION_IS_GIT_SNAPSHOT=no When updating the version you can run this to regenerate the version: $ make version-update The version can be determined in Python by using ipaserver.version.VERSION
2008-04-30 16:49:52 -05:00
########################################################
# For 'rc' releases the version will be #
# #
# <MAJOR>.<MINOR>.<RELEASE>rc<RC_RELEASE> #
# #
# e.g. IPA_VERSION_RC_RELEASE=1 #
# -> "1.0.0rc1" #
########################################################
Become IPA 2.0.0
2011-03-24 15:28:53 -05:00
IPA_VERSION_RC_RELEASE=
Redo the way versioning works in freeIPA. The file VERSION is now the sole-source of versioning. The generated .spec files will been removed in the maintainer-clean targets and have been removed from the repository. By default a GIT build is done. To do a non-GIT build do: $ make TARGET IPA_VERSION_IS_GIT_SNAPSHOT=no When updating the version you can run this to regenerate the version: $ make version-update The version can be determined in Python by using ipaserver.version.VERSION
2008-04-30 16:49:52 -05:00
########################################################
# To mark GIT snapshots this should be set to 'yes' #
# in the development BRANCH, and set to 'no' only in #
# the IPA_X_X_RELEASE BRANCH #
# #
# <MAJOR>.<MINOR>.<RELEASE>GITxxx #
# #
# e.g. IPA_VERSION_IS_SVN_SNAPSHOT=yes #
# -> "1.0.0GITabcdefg" #
########################################################
IPA_VERSION_IS_GIT_SNAPSHOT="yes"
Replication version checking. Whenever we upgrade IPA such that any data incompatibilities might occur then we need to bump the DATA_VERSION value so that data will not replicate to other servers. The idea is that you can do an in-place upgrade of each IPA server and the different versions own't pollute each other with bad data.
2010-06-24 09:31:52 -05:00
########################################################
# The version of IPA data. This is used to identify #
# incompatibilities in data that could cause issues #
# with replication. If the built-in versions don't #
# match exactly then replication will fail. #
# #
# The format is %Y%m%d%H%M%S #
# #
# e.g. IPA_DATA_VERSION=`date +%Y%m%d%H%M%S` #
# -> "20100614120000" #
########################################################
IPA_DATA_VERSION=20100614120000
Add API version and have server reject incompatible clients. This patch contains 2 parts. The first part is a small utility to create and validate the current API. To do this it needs to load ipalib which on a fresh system introduces a few problems, namely that it relies on a python plugin to set the default encoding to utf8. For our purposes we can skip that. It is also important that any optional plugins be loadable so the API can be examined. The second part is a version exchange between the client and server. The version has a major and a minor version. The major verion is updated whenever existing API changes. The minor version is updated when new API is added. A request will be rejected if either the major versions don't match or if the client major version is higher than then server major version (though by implication new API would return a command not found if allowed to proceed). To determine the API version of the server from a client use the ping command. ticket 584
2011-01-13 13:29:16 -06:00
########################################################
# The version of the IPA API. This controls which #
# client versions can use the XML-RPC and json APIs #
# #
# A change to existing API requires a MAJOR version #
# update. The addition of new API bumps the MINOR #
# version. #
# #
# The format is a whole number #
# #
########################################################
IPA_API_VERSION_MAJOR=2
Add reverse DNS record when forward is created Adding reverse DNS record may be a time consuming task, especially for IPv6 addresses. Having a way to automatically create a reverse record when a forward record is created could speed up the process. host-add command already has this possibility. This patch takes advantage of the new per-type API and adds new options for A/AAAA record types: --a-create-reverse and --aaaa-create-reverse. These commands can be used to automatically create reverse records for new A/AAAA addresses (both forward and reverse zones need to be managed by FreeIPA server): ipa dnsrecord-add example.com foo --a-rec=10.0.0.1 --a-create-reverse This command would add a new A record to record foo in zone example.com and a PTR record to appropriate reverse zone for IP address 10.0.0.1 (for example PTR record 1 in zone 0.0.10.in-addr.arpa. pointing to foo.example.com.). Few modification were done to new DNS API to support this feature: - Refactor --ip-address option handling from host-add and place it to dns.py to be used by both modules - Add support for "extra" per-type options - Hide DNS record part options in dnsrecord_find command as they have no effect for this command https://fedorahosted.org/freeipa/ticket/2009
2012-02-24 07:15:24 -06:00
IPA_API_VERSION_MINOR=27
Reference in New Issue Copy Permalink