From: Guenter M. <mi...@us...> - 2017-06-21 14:18:55
|
On 2017-06-20, David Goodger wrote: > On Mon, Jun 19, 2017 at 4:05 PM, Guenter Milde via Docutils-develop ><doc...@li...> wrote: >> Alpha/beta/etc. are commonly used and recognized to denote >> the `development status`__. >> __ https://blog.codinghorror.com/alpha-beta-and-sometimes-gamma/ >> Therefore I have the following >> Suggestions >> =========== >> 1. releaselevel == development status >> ------------------------------------- >> Don't use release level '(repository)' or '!repository' or ''. >> The information "repository" vs. "release" is already encoded as: >> release = False Suffix ".dev" >> release = True no developmental release segment >> Instead, use `releaselevel` for the development status of either >> * the repository (if release == False) or >> * the release (if release == True). > +1 >> Motivation: even if no release is planned, the repository has a >> development status in the sense that we can recommend it for >> alpha internal testing, >> beta external testing, >> candidate pre-test of an upcoming release, >> final production use and inclusion in distributions >> I have no clear preference whether to keep the name or call it >> ``development_status`` instead. > My clear preference is to keep the name "releaselevel", because that's > what sys.version_info calls it. Record that "releaselevel = > development status" in the docstring. Done. >> 2. default repository status == "beta" >> -------------------------------------- ... > It seems odd to start at "beta". Just as easy to make "alpha" the > default development status, and skip "beta". Given that we agree on >> 1. releaselevel == development status it seems rather odd to mark the repository status as "alpha" (experimental, for internal tests only, expect breakage and data loss) after every release (even without any other change)! > But we can use "beta" for now. In future, if we find that we need an > "alpha" status, we can start using it then. ... and also discuss details if the need arises rather than now. >> * To keep the repository reasonably small, older maintenance branches should >> be deleted (moved to the attic). Version control ensures they can be >> revived if required. OK to `svn delete` branch "docutils-0.4"? ... > And **again**, the whole point of __version_info__ is to remove any > need to parse __version__. The point was to offer __version_info__ as a service so that **clients** don't need to parse __version__ (to prevent parsing errors like the already fixed one in Sphinx). This does not bar us from parsing __version__ ourselfs (in a script or sub-module) instead of forcing the release manager to maintain __version_info__ "per hand". > What we have now is fine, and what we'll have in 0.15 is better, more > than good enough. So, as "mathjax URL" and "__version_info__" are solved, lets release 0.14. Günter |