pingu_98/MrDraw
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
MrDraw/.versioneer-lookup

34 lines
1.2 KiB
Text
Raw Normal View History

Modified versioneer to allow specification of manual versions based on branches You can now define a lookup file explicitely mapping virtual version tags to branches via regular expressions and a reference commit from which the commit distance will be calculated. Format of the file is <branch-regex> <tag> <reference commit> The file is processed from top to bottom, the first matching line wins. If <tag> or <reference commit> are left out, the lookup table does not apply to the matched branches and the regular versioneer resolution (via git describe) takes place. Current configuration makes "master", "staging" and any branch starting with "fix/" make use the default behaviour, all other branches (so basically all development branches) are defined as "1.2.0-dev"
2014-09-02 09:35:42 +00:00
# Configuration file for the versioneer lookup, manually mapping tags based on branches
#
# Format is
#
# <branch-regex> <tag> <reference commit>
#
# The file is processed from top to bottom, the first matching line wins. If <tag> or <reference commit> are left out,
# the lookup table does not apply to the matched branches
First throw at release channels We start out with master (Stable), rc/maintenance (Maintenance) and rc/devel (Devel)
2016-08-24 17:02:39 +00:00
# master and rc shall not use the lookup table, only tags
added our own mrbeam2 branches to allow for tag lookup.
2017-04-12 08:42:23 +00:00
mrbeam2-dev
mrbeam2-stable
Modified versioneer to allow specification of manual versions based on branches You can now define a lookup file explicitely mapping virtual version tags to branches via regular expressions and a reference commit from which the commit distance will be calculated. Format of the file is <branch-regex> <tag> <reference commit> The file is processed from top to bottom, the first matching line wins. If <tag> or <reference commit> are left out, the lookup table does not apply to the matched branches and the regular versioneer resolution (via git describe) takes place. Current configuration makes "master", "staging" and any branch starting with "fix/" make use the default behaviour, all other branches (so basically all development branches) are defined as "1.2.0-dev"
2014-09-02 09:35:42 +00:00
master
First throw at release channels We start out with master (Stable), rc/maintenance (Maintenance) and rc/devel (Devel)
2016-08-24 17:02:39 +00:00
rc/.*
Added new prerelease branch to versioneer config Can be used in the future for tracking prereleases and testing proper version updates without having to push to master directly.
2016-06-08 09:19:21 +00:00
prerelease
Modified versioneer to allow specification of manual versions based on branches You can now define a lookup file explicitely mapping virtual version tags to branches via regular expressions and a reference commit from which the commit distance will be calculated. Format of the file is <branch-regex> <tag> <reference commit> The file is processed from top to bottom, the first matching line wins. If <tag> or <reference commit> are left out, the lookup table does not apply to the matched branches and the regular versioneer resolution (via git describe) takes place. Current configuration makes "master", "staging" and any branch starting with "fix/" make use the default behaviour, all other branches (so basically all development branches) are defined as "1.2.0-dev"
2014-09-02 09:35:42 +00:00
Fixed version reporting on detached HEADs HEAD "branch" also should disable usage of lookup table.
2015-11-20 12:54:09 +00:00
# neither should disconnected checkouts, e.g. 'git checkout <tag>'
HEAD
\(detached.*
maintenance & staging/maintenance are now 1.3.5(rc1)
2017-06-01 14:09:34 +00:00
# maintenance is currently the branch for preparation of maintenance release 1.3.5
Make improve/... branches behave as maintenance branches Felt too wrong to call improvements fixes all the time.
2016-02-09 16:55:29 +00:00
# so are any fix/... and improve/... branches
maintenance is now 1.3.6.dev, staging is 1.3.5rc2.dev
2017-07-26 12:24:30 +00:00
maintenance 1.3.6 1a6dbb3f4a5bef857cdeb13c031b9deca2cf30a2 pep440-dev
fix/.* 1.3.6 1a6dbb3f4a5bef857cdeb13c031b9deca2cf30a2 pep440-dev
improve/.* 1.3.6 1a6dbb3f4a5bef857cdeb13c031b9deca2cf30a2 pep440-dev
Modified versioneer to allow specification of manual versions based on branches You can now define a lookup file explicitely mapping virtual version tags to branches via regular expressions and a reference commit from which the commit distance will be calculated. Format of the file is <branch-regex> <tag> <reference commit> The file is processed from top to bottom, the first matching line wins. If <tag> or <reference commit> are left out, the lookup table does not apply to the matched branches and the regular versioneer resolution (via git describe) takes place. Current configuration makes "master", "staging" and any branch starting with "fix/" make use the default behaviour, all other branches (so basically all development branches) are defined as "1.2.0-dev"
2014-09-02 09:35:42 +00:00
staging is 1.3.5rc4.dev
2017-08-25 12:56:15 +00:00
# staging/maintenance is currently the branch for preparation of 1.3.5rc4
Do not run subprocesses while intermediary server is active Any processes inheriting the open port descriptor of that server will cause the actual server startup to fail due to the port still being claimed. We can't fully prevent this under Windows thanks to fnctl not being available and win32api being a PITA, and also close_fds on Popen not being allowed if we also need to redirect stdout/stderr/stdin for a process. So let's hope hardening against this problem when running under *nix, adding a bit fat warning to never start a subprocess during the intermediary's runtime and also moving the only actual process we so far DID start (analysis backlog processing) to after Tornado is running will suffice. Fixes #2035
2017-07-27 07:58:20 +00:00
# so is regressionfix/...
staging is 1.3.5rc4.dev
2017-08-25 12:56:15 +00:00
staging/maintenance 1.3.5rc4 679674df2282af0c4500367fa93864c6defa3802 pep440-dev
regressionfix/.* 1.3.5rc4 679674df2282af0c4500367fa93864c6defa3802 pep440-dev
Modified versioneer to allow specification of manual versions based on branches You can now define a lookup file explicitely mapping virtual version tags to branches via regular expressions and a reference commit from which the commit distance will be calculated. Format of the file is <branch-regex> <tag> <reference commit> The file is processed from top to bottom, the first matching line wins. If <tag> or <reference commit> are left out, the lookup table does not apply to the matched branches and the regular versioneer resolution (via git describe) takes place. Current configuration makes "master", "staging" and any branch starting with "fix/" make use the default behaviour, all other branches (so basically all development branches) are defined as "1.2.0-dev"
2014-09-02 09:35:42 +00:00
Upped version numbers for branches
2016-12-08 13:04:28 +00:00
# every other branch is a development branch and thus gets resolved to 1.4.0-dev for now
.* 1.4.0 7f5d03d0549bcbd26f40e7e4a3297ea5204fb1cc pep440-dev
Reference in a new issue Copy permalink