From: David G. <go...@py...> - 2017-06-22 16:31:51
|
On Wed, Jun 21, 2017 at 9:39 AM, Guenter Milde via Docutils-develop <doc...@li...> wrote: > On 2017-06-20, David Goodger wrote: >> On Mon, Jun 19, 2017 at 4:05 PM, Guenter Milde via Docutils-develop > > >>> * "Beta" seems the best match when comparing the `description of the >>> development stages`__ with the state of the repository and our release >>> policies --- which state that the code in the repository is >>> a) *experimental* until the major version number reaches 1 and >>> b) always kept in a *stable* state (usable and as problem-free as >>> possible). > >>> __ https://en.wikipedia.org/wiki/Software_release_life_cycle > >>> * In Docutils' ``setup.py``, we use the trove classifier :: > >>> 'Development Status :: 4 - Beta', > >> We can and should change this to match the actual status, on an ongoing >> basis. > > I suggest to > > * Update the policies to reflect the status of the last discussions. > (See patch below.) I have one edit, below. > * Keep the trove classifier at "4 - Beta" (also for final releases) until > we reach 1.0. > Change the trove classifier to "5 - Production/Stable" > with final release 1.0 > > After 1.0, it should be 4-Beta for the repository and pre-releases and > 5-Stable for final releases. Sounds good. > Index: policies.txt > =================================================================== > --- policies.txt (Revision 8113) > +++ policies.txt (Arbeitskopie) > @@ -285,14 +285,12 @@ > core**) is used for active -- but stable, fully tested, and reviewed > -- development. > > -There will be at least one active **maintenance branch** at a time, > -based on at least the latest feature release. For example, when > -Docutils 0.5 is released, its maintenance branch will take over, and > -the 0.4.x maintenance branch may be retired. Maintenance branches > -will receive bug fixes only; no new features will be allowed here. > +If we need to cut a bugfix release, we'll create a **maintenance branch** > +based on the latest feature release. For example, when Docutils 0.5 is > +released, this would be ``branches/docutils-0.5``, and an eventually > +existing 0.4.x maintenance branch may be retired. Maintenance branches will "and an eventually existing 0.4.x maintenance branch may be retired" doesn't parse. Suggest "and any existing 0.4.x maintenance branches may be retired". David Goodger <http://python.net/~goodger> > +receive bug fixes only; no new features will be allowed here. > > -.. TODO: is this still active policy? > - > Obvious and uncontroversial bug fixes *with tests* can be checked in > directly to the core and to the maintenance branches. Don't forget to > add test cases! Many (but not all) bug fixes will be applicable both > @@ -411,12 +409,10 @@ > Docutils version numbering uses a ``major.minor.micro`` scheme (x.y.z; > for example, 0.4.1). > > -**Major releases** (x.0, e.g. 1.0) will be rare, and will represent > -major changes in API, functionality, or commitment. For example, as > -long as the major version of Docutils is 0, it is to be considered > -*experimental code*. When Docutils reaches version 1.0, the major > -APIs will be considered frozen and backward compatibility will become > -of paramount importance. > +**Major releases** (x.0, e.g. 1.0) will be rare, and will represent major > +changes in API, functionality, or commitment. When Docutils reaches version > +1.0, the major APIs will be considered frozen and backward compatibility > +will become of paramount importance. > > Releases that change the minor number (x.y, e.g. 0.5) will be > **feature releases**; new features from the `Docutils core`_ will be > @@ -431,7 +427,8 @@ > official version numbering policy, and micro releases contained both > bug fixes and new features. > > -See also the `Docutils Release Procedure`_. > +See also the `Docutils Release Procedure`_, `docutils.__version__` and > +`docutils.__version_info__`. > > .. _Docutils Release Procedure: release.html#version-numbers |