Lines Matching +full:pre +full:- +full:release
2 ------------------------------------------------
5 track finer-grained version increments than you would normally use for e.g.
10 therefore may literally need an up-to-the-minute version of something!
16 * A manually-specified pre-release tag, such as "build" or "dev", or a
17 manually-specified post-release tag, such as a build or revision number
18 (``--tag-build=STRING, -bSTRING``)
20 * An 8-character representation of the build date (``--tag-date, -d``), as
28 (Also, before you release your project, be sure to see the section on
29 :ref:`Specifying Your Project's Version` for more information about how pre- and
30 post-release tags affect how version numbers are interpreted. This is
37 delete all but the N most-recently-modified distributions matching a glob
40 setup.py egg_info -rbDEV bdist_egg rotate -m.egg -k3
42 to build an egg whose version info includes "DEV-rNNNN" (where NNNN is the
52 directory. (And, you could also define sitewide or per-user default versions
57 -------------------------------
77 project's ``.egg-info`` directory, out of the way of your main project
78 directory. You therefore need not worry about whether it is up-to-date or not.
83 all practical purposes, you'll probably use only the ``--formats`` option, if
87 Making "Official" (Non-Snapshot) Releases
90 When you make an official release, creating source or binary distributions,
92 don't end up registering versions like ``foobar-0.7a1.dev-r34832``. This is
94 your releases - just make the change to ``setup.cfg`` after branching or
95 tagging the release, so the trunk will still produce development snapshots.
100 setup.py egg_info -Db "" sdist bdist_egg
102 The first part of this command (``egg_info -Db ""``) will override the
110 setup.py alias -u release egg_info -Db ""
114 setup.py release sdist bdist_egg
121 --------------------------------------------
126 To ensure Cython is available, include Cython in the build-requires section
129 [build-system]
134 setup-requires of setup.cfg::
162 ---------------------------------
166 `PEP 440 <https://www.python.org/dev/peps/pep-0440/>`_ scheme, but it
173 A version consists of an alternating series of release numbers and pre-release
174 or post-release tags. A release number is a series of digits punctuated by
177 same release number, denoting the first subrelease of release 2. But ``2.10``
178 is the *tenth* subrelease of release 2, and so is a different and newer release
182 Following a release number, you can have either a pre-release or post-release
183 tag. Pre-release tags make a version be considered *older* than the version
187 revisions like ``2.4-1`` are newer than ``2.4``, but *older*
188 than ``2.4.1`` (which has a higher release number).
191 older than non-legacy versions. Taking that in count, a revision ``2.4pl1``
194 A pre-release tag is a series of letters that are alphabetically before
198 do so if you prefer. Thus, ``2.4c1`` and ``2.4.c1`` and ``2.4-c1`` all
199 represent release candidate 1 of version ``2.4``, and are treated as identical
203 they were the letter ``c``: ``pre``, ``preview``, and ``rc``. So, version
207 A post-release tag is either a series of letters that are alphabetically
208 greater than or equal to "final", or a dash (``-``). Post-release tags are
210 numbers, or date stamps from the release number. For example, the version
211 ``2.4-r1263`` might denote Subversion revision 1263 of a post-release patch of
212 version ``2.4``. Or you might use ``2.4-20051127`` to denote a date-stamped
213 post-release.
215 Notice that after each pre or post-release tag, you are free to place another
216 release number, followed again by more pre- or post-release tags. For example,
217 ``0.6a9.dev-r41475`` could denote Subversion revision 41475 of the in-
218 development version of the ninth alpha of release 0.6. Notice that ``dev`` is
219 a pre-release tag, so this version is a *lower* version number than ``0.6a9``,
220 which would be the actual ninth alpha of release 0.6. But the ``-r41475`` is
221 a post-release tag, so this version is *newer* than ``0.6a9.dev``.
226 * Don't stick adjoining pre-release tags together without a dot or number
228 *not* a development pre-release of ``1.9a``. Use ``.dev`` instead, as in
241 >>> parse_version("2.1-rc2") < parse_version("2.1")
243 >>> parse_version("0.6a9dev-r41475") < parse_version("0.6a9")
247 have setuptools automatically tag your in-development releases with various
248 pre- or post-release tags. See the following sections for more details: