[Docutils-develop] feature freeze for release 0.14

sorry made 0.14.0a and read afterwards

snd after rereading PEP440

[N!]N(.N)*[{a|b|rc}N][.postN][.devN]

i see it should be "0.14a0" "or "0.14rc1"

maybe next time i get it right. sorry

i did not mark 0.14 as latest on sf.
and on pypi 0.13 is not hidden

so maybe/hopefully automatic tools do not upgrade to 0.14

cheers

Dear Engelbert,

the plan

Thank you for the plan and for taking care of the release.

Yes, thanks!
* Announce the date of the feature freeze, at least a week away. Just
saying "feature freeze now" is not OK.

* make a prerelease 0.14.1a

& announce/release!

* wait some time
* maybe 0.14.1b if necessary
* ...
(0.14.1rc1 ...
release 0.14.1
this might take up to two weeks
any comments welcome

I agree with GÃŒnter. 0.14a/b/rc1/... then release 0.14.
0.14.1 (after first +a/b/rc...) is for any bugfix release to 0.14.

a) increase the version number of the SVN repo to 0.14a

And announce, get feedback.

b) make a pre-release 0.14rc1

And announce, get feedback. At every interim release.

Sure.
David

may

call it b(eta) or rc1 (I can live with both but I don't think we need
both beta and rcN).
c) The sort order of version numbers in PEP 440 is
0.14a < 0.14 == 0.14.0 < 0.14.1a < 0.14.1
so the first release in the 0.14 series can be 0.14.
(We skipped 0.13.0, because the SVN version was already at 0.13

instead

of 0.13a but this is no problem this time.)
Thanks,
GÃŒnter

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
https://lists.sourceforge.net/lists/listinfo/docutils-develop
Please use "Reply All" to reply to the list.

engelbert gruber

2017-05-27 11:49:26 UTC

i try and hope it is safe to remove the release 0.14.0a and reprerelease
0.14a0

Post by engelbert gruber
sorry made 0.14.0a and read afterwards
snd after rereading PEP440
[N!]N(.N)*[{a|b|rc}N][.postN][.devN]
i see it should be "0.14a0" "or "0.14rc1"
maybe next time i get it right. sorry
i did not mark 0.14 as latest on sf.
and on pypi 0.13 is not hidden
so maybe/hopefully automatic tools do not upgrade to 0.14
cheers

Dear Engelbert,

the plan

Thank you for the plan and for taking care of the release.

Yes, thanks!
* Announce the date of the feature freeze, at least a week away. Just
saying "feature freeze now" is not OK.

* make a prerelease 0.14.1a

& announce/release!

* wait some time
* maybe 0.14.1b if necessary
* ...
(0.14.1rc1 ...
release 0.14.1
this might take up to two weeks
any comments welcome

I agree with GÃŒnter. 0.14a/b/rc1/... then release 0.14.
0.14.1 (after first +a/b/rc...) is for any bugfix release to 0.14.

a) increase the version number of the SVN repo to 0.14a

And announce, get feedback.

b) make a pre-release 0.14rc1

And announce, get feedback. At every interim release.

Sure.
David

may

instead

of 0.13a but this is no problem this time.)
Thanks,
GÃŒnter

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
https://lists.sourceforge.net/lists/listinfo/docutils-develop
Please use "Reply All" to reply to the list.

engelbert gruber

2017-05-27 13:10:25 UTC

RFC

and this is a feature freeze, meaning ... be cautious

commits regarding bugs (bugs ain't no feature :-) are ok
commits enhancing documentation is always welcome

if a new prerelease should be send to pypi/sf notify me

i think i will replace the previous prerelease and accumulate the changes
in HISTORY and RELEASE-NOTES

Post by engelbert gruber
i try and hope it is safe to remove the release 0.14.0a and reprerelease
0.14a0

Dear Engelbert,

the plan

Thank you for the plan and for taking care of the release.

Yes, thanks!
* Announce the date of the feature freeze, at least a week away. Just
saying "feature freeze now" is not OK.

* make a prerelease 0.14.1a

& announce/release!

* wait some time
* maybe 0.14.1b if necessary
* ...
(0.14.1rc1 ...
release 0.14.1
this might take up to two weeks
any comments welcome

I agree with GÃŒnter. 0.14a/b/rc1/... then release 0.14.
0.14.1 (after first +a/b/rc...) is for any bugfix release to 0.14.

a) increase the version number of the SVN repo to 0.14a

And announce, get feedback.

b) make a pre-release 0.14rc1

And announce, get feedback. At every interim release.

Sure.
David

may

call it b(eta) or rc1 (I can live with both but I don't think we

need

both beta and rcN).
c) The sort order of version numbers in PEP 440 is
0.14a < 0.14 == 0.14.0 < 0.14.1a < 0.14.1
so the first release in the 0.14 series can be 0.14.
(We skipped 0.13.0, because the SVN version was already at 0.13

instead

of 0.13a but this is no problem this time.)
Thanks,
GÃŒnter

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
https://lists.sourceforge.net/lists/listinfo/docutils-develop
Please use "Reply All" to reply to the list.

Guenter Milde

2017-05-27 15:12:06 UTC

Dear Engelbert, dear David, dear Docutils developers,

Post by engelbert gruber
and this is a feature freeze, meaning ... be cautious
commits regarding bugs (bugs ain't no feature :-) are ok
commits enhancing documentation is always welcome

OK. Thank you for the clarification.

Post by engelbert gruber
if a new prerelease should be send to pypi/sf notify me

Maybe we could agree on the "name" (number) of the next prerelease first
(see suggestion below).

Post by engelbert gruber
I think I will replace the previous prerelease and accumulate the changes
in HISTORY and RELEASE-NOTES

Yes, please. Also the final release section should IMO replace the
pre-release sections in HISTORY and RELEASE-NOTES (with the accumulated
change notes).

Post by engelbert gruber
sorry made 0.14.0a and read afterwards

...

Post by engelbert gruber
i see it should be "0.14a0" "or "0.14rc1"

PEP 440 says

* When comparing release segments with different numbers of components,
the shorter segment is padded out with additional zeros as necessary.

* Pre releases allow omitting the numeral in which case it is implicitly
assumed to be 0.

so for the sake of ordering,

0.14a0 == 0.14a == 0.14.0a == 0.14.0a0

No damage done :-)

As a convention for Docutils version numbers, I suggest

* Omitting the micro number if it is "0" (as we did in the past).

* Skipping "alpha" and "beta" pre-releases.

PEP 440 sort order is: 0.9 < 1.0.dev < 1.0a1 < 1.0a2 < 1.0b1 < 1.0rc1 < 1.0

However,
"alpha" generally means "experimental, use with caution" but on
http://docutils.sourceforge.net/, we write

We recommend that you use a snapshot from Docutils' Subversion
repository. The snapshots usually contain *more features* and *fewer
bugs* than the "official" releases—they're not only for developers!

Labeling a release that is basically a double checked snapshot (i.e.
containing "fewer bugs than the 'official' releases") an
"alpha-release" seems inconsistent.

For the same reason, I would use the ".dev" suffix instead of "a" for
the repository version after the final release.

Post by engelbert gruber
i did not mark 0.14 as latest on sf.
and on pypi 0.13 is not hidden
so maybe/hopefully automatic tools do not upgrade to 0.14

Seems to work: I tested this with the "pip" command line tool:

`pip install docutils` installs 0.13.1

`pip install --pre docutils` installs 0.14.0a

So, my suggestion is to release 0.14rc1
and announce it on docutils-users, sphinx-usrers and sphinx-devel.

Günter

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
Docutils-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-develop

Plea

engelbert gruber

2017-05-27 15:33:07 UTC

ok 0.14rc1

i initially appended "a" because the bug report said

These can then all be pushed to pypi.python.org and by default pip will
install the latest release
unless explicitly requested via the --pre flag or a version specifier
docutils>=0.13.1a

so no normal user gets a prerelease.

numbering

today: prerelease 0.14rc1
someday: release 0.14

and what to do in the repo:

- repository 0.14.dev: somehow looks like a predecessor to 0.14
- repository 0.15.dev: but what if we do a 0.14.1
- repository 0.14.1.dev: although 0.14.1 might be 0.15

cheers

Post by Guenter Milde
Dear Engelbert, dear David, dear Docutils developers,

Post by engelbert gruber
and this is a feature freeze, meaning ... be cautious
commits regarding bugs (bugs ain't no feature :-) are ok
commits enhancing documentation is always welcome

OK. Thank you for the clarification.

Post by engelbert gruber
if a new prerelease should be send to pypi/sf notify me

Maybe we could agree on the "name" (number) of the next prerelease first
(see suggestion below).

Post by engelbert gruber
I think I will replace the previous prerelease and accumulate the changes
in HISTORY and RELEASE-NOTES

Yes, please. Also the final release section should IMO replace the
pre-release sections in HISTORY and RELEASE-NOTES (with the accumulated
change notes).

Post by engelbert gruber
sorry made 0.14.0a and read afterwards

...

Post by engelbert gruber
i see it should be "0.14a0" "or "0.14rc1"

PEP 440 says
* When comparing release segments with different numbers of components,
the shorter segment is padded out with additional zeros as necessary.
* Pre releases allow omitting the numeral in which case it is implicitly
assumed to be 0.
so for the sake of ordering,
0.14a0 == 0.14a == 0.14.0a == 0.14.0a0
No damage done :-)
As a convention for Docutils version numbers, I suggest
* Omitting the micro number if it is "0" (as we did in the past).
* Skipping "alpha" and "beta" pre-releases.
PEP 440 sort order is: 0.9 < 1.0.dev < 1.0a1 < 1.0a2 < 1.0b1 < 1.0rc1 < 1.0
However,
"alpha" generally means "experimental, use with caution" but on
http://docutils.sourceforge.net/, we write
We recommend that you use a snapshot from Docutils' Subversion
repository. The snapshots usually contain *more features* and *fewer
bugs* than the "official" releasesâthey're not only for developers!
Labeling a release that is basically a double checked snapshot (i.e.
containing "fewer bugs than the 'official' releases") an
"alpha-release" seems inconsistent.
For the same reason, I would use the ".dev" suffix instead of "a" for
the repository version after the final release.

Post by engelbert gruber
i did not mark 0.14 as latest on sf.
and on pypi 0.13 is not hidden
so maybe/hopefully automatic tools do not upgrade to 0.14

`pip install docutils` installs 0.13.1
`pip install --pre docutils` installs 0.14.0a
So, my suggestion is to release 0.14rc1
and announce it on docutils-users, sphinx-usrers and sphinx-devel.
GÃŒnter
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
https://lists.sourceforge.net/lists/listinfo/docutils-develop
Please use "Reply All" to reply to the list.

Guenter Milde

2017-05-27 18:10:33 UTC

[-- Type: text/plain, Encoding: quoted-printable --]
ok 0.14rc1
i initially appended "a" because the bug report said

I understand. But IMO, this was just a suggestion/example.

numbering
today: prerelease 0.14rc1
someday: release 0.14
- repository 0.14.dev: somehow looks like a predecessor to 0.14

Yes, this would be < 0.14 (actually even < 0.14rcN < 0.14)

- repository 0.15.dev: but what if we do a 0.14.1
- repository 0.14.1.dev: although 0.14.1 might be 0.15
today: prerelease 0.14rc1

With the next commit to the repository, bump repo version to 0.14rc2.dev

someday: release 0.14

With the next commit to the repository, bump repo version to 0.14.1.dev

With the first "new feature commit", bump repo version to 0.15.dev.

Once the repository reaches a state considered to be fine for 1.0,
bump repo version to 1.0dev.

General idea:

The repository version number is always

* equal to the last released version until there is some change,

* increased to "<next possible release>.dev".

<next possible release> is the version number a repository snapshot
would be given if released. It depends on the changes (bugfix only vs.
new feature vs. major changes).

Motivation:

* An installed snapshot will be "higher" than the last release but
"lower" than the next release.

Users that want to switch between snapshot and release versions can do so
easily via pip.

* The version number of the snapshot indicates the nature of changes to the
last release (bugfix, new feature, API change).

Günter

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
Docutils-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-develop

Please use "Reply All"

David Goodger

2017-05-28 18:55:23 UTC

[-- Type: text/plain, Encoding: quoted-printable --]
ok 0.14rc1
i initially appended "a" because the bug report said

I understand. But IMO, this was just a suggestion/example.

numbering
today: prerelease 0.14rc1
someday: release 0.14
- repository 0.14.dev: somehow looks like a predecessor to 0.14

Yes, this would be < 0.14 (actually even < 0.14rcN < 0.14)

To clarify, the version in the repo after the 0.14 release would *NOT*
be 0.14.dev. It would be 0.15.dev.

- repository 0.15.dev: but what if we do a 0.14.1

+1 on 0.15.dev as repository versioning of the trunk after the release of 0.14.

What if we do a 0.14.1? That's a branch, not the trunk. It branches
off of the 0.14 release.

- repository 0.14.1.dev: although 0.14.1 might be 0.15

-1. Micro releases are only in case of bugfix-only releases, and they
use branches.

today: prerelease 0.14rc1

With the next commit to the repository, bump repo version to 0.14rc2.dev

someday: release 0.14

With the next commit to the repository, bump repo version to 0.14.1.dev

-1, as we shouldn't expect a bugfix release. We want to be able to
commit new features to the trunk.

If you want to start a 0.14.1.dev *branch*, fine. But it has to be a new branch!

Post by Guenter Milde
With the first "new feature commit", bump repo version to 0.15.dev.

-1, for reasons stated. This would just confuse things.

Post by Guenter Milde
Once the repository reaches a state considered to be fine for 1.0,
bump repo version to 1.0dev.

correction: 1.0.dev. Right?

Post by Guenter Milde
The repository version number is always
* equal to the last released version until there is some change,

-1. Instead: equal to the last released minor version + 1, with a .dev suffix.

Post by Guenter Milde
* increased to "<next possible release>.dev".

+1, where <next possible release> = <major>.<minor+1>.

Post by Guenter Milde
<next possible release> is the version number a repository snapshot
would be given if released. It depends on the changes (bugfix only vs.
new feature vs. major changes).
* An installed snapshot will be "higher" than the last release but
"lower" than the next release.
Users that want to switch between snapshot and release versions can do so
easily via pip.
* The version number of the snapshot indicates the nature of changes to the
last release (bugfix, new feature, API change).
Günter

David Goodger
<http://python.net/~goodger>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
Docutils-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-develop

Please use "Reply All" to

engelbert gruber

2017-05-29 15:00:16 UTC

versionnumbering example:

* "repository 0.14.dev" (that is with what we should have started)
* release canditate: "prerelease 0.14rc1" release and increase
* "repository 0.14rc2.dev"
* if nothing happens, no rc2 necessary, "release 0.14" increase
* "repository 0.15.dev"
* in case a bugfix release is necessary: "release 0.14.1"
* repo stays(switches back to) "repository 0.15.dev"

this means i should change repository to 0.14rc2.dev ... right ?

[-- Type: text/plain, Encoding: quoted-printable --]
ok 0.14rc1
i initially appended "a" because the bug report said

I understand. But IMO, this was just a suggestion/example.

numbering
today: prerelease 0.14rc1
someday: release 0.14
- repository 0.14.dev: somehow looks like a predecessor to 0.14

Yes, this would be < 0.14 (actually even < 0.14rcN < 0.14)

To clarify, the version in the repo after the 0.14 release would *NOT*
be 0.14.dev. It would be 0.15.dev.

- repository 0.15.dev: but what if we do a 0.14.1

+1 on 0.15.dev as repository versioning of the trunk after the release of 0.14.
What if we do a 0.14.1? That's a branch, not the trunk. It branches
off of the 0.14 release.

- repository 0.14.1.dev: although 0.14.1 might be 0.15

-1. Micro releases are only in case of bugfix-only releases, and they
use branches.

today: prerelease 0.14rc1

With the next commit to the repository, bump repo version to 0.14rc2.dev

someday: release 0.14

With the next commit to the repository, bump repo version to 0.14.1.dev

-1, as we shouldn't expect a bugfix release. We want to be able to
commit new features to the trunk.
If you want to start a 0.14.1.dev *branch*, fine. But it has to be a new branch!

Post by Guenter Milde
With the first "new feature commit", bump repo version to 0.15.dev.

-1, for reasons stated. This would just confuse things.

Post by Guenter Milde
Once the repository reaches a state considered to be fine for 1.0,
bump repo version to 1.0dev.

correction: 1.0.dev. Right?

Post by Guenter Milde
The repository version number is always
* equal to the last released version until there is some change,

-1. Instead: equal to the last released minor version + 1, with a .dev suffix.

Post by Guenter Milde
* increased to "<next possible release>.dev".

+1, where <next possible release> = <major>.<minor+1>.

Post by Guenter Milde
easily via pip.
* The version number of the snapshot indicates the nature of changes to

the

Post by Guenter Milde
last release (bugfix, new feature, API change).
GÃŒnter

David Goodger
<http://python.net/~goodger>
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
https://lists.sourceforge.net/lists/listinfo/docutils-develop
Please use "Reply All" to reply to the list.

Guenter Milde

2017-05-29 20:24:17 UTC

Post by engelbert gruber
* "repository 0.14.dev" (that is with what we should have started)
* release canditate: "prerelease 0.14rc1" release and increase
* "repository 0.14rc2.dev"
* if nothing happens, no rc2 necessary, "release 0.14" increase
* "repository 0.15.dev"
* in case a bugfix release is necessary: "release 0.14.1"
* repo stays(switches back to) "repository 0.15.dev"

This is how I understood David.

Post by engelbert gruber
this means i should change repository to 0.14rc2.dev ... right ?

If it is not too much work, yes (would allow to install a daily
snapshot over prerelease 0.14.rc1) easily. But it is not urgent IMO.

May I suggest adding a summary of the discussion to "release.txt"
(patch below, comments and corrections welcome)?

Günter

Index: release.txt
===================================================================
--- release.txt (Revision 8090)
+++ release.txt (Arbeitskopie)
@@ -45,36 +45,20 @@
Version numbers shall follow the `Docutils Project Policies`_ and comply
with `PEP 440`_.

-From `Feature Request #50`_
+Especially, mark pre-releases and the repository version/snapshots as
+"between" releases (cf. `Feature Request #50`_ and the discussion on
+docutils-devel on May 28 2017), e.g.

- PEP 440 specifies how release version are understood by pip and other tools.
+| prev. release 0.13.1,
+| prerelease 0.14rc1,
+| [prereleases 0.14rc2, ...]
+| release 0.14,
+| repo/snapshots 0.15.dev
+| [bugfix relases 0.14.1, ...] # branches off of the 0.14 release.

- The last released package of docutils was in 2014.
+The repository version number is always equal to the last released
+version + 1, with a .dev suffix: ``<major>.<minor+1>.dev``.

- If you install the version from Source it will not be overriden by version
- 0.13 when it is eventaully released.
-
- As folks have installed 0.13 from indeterminate source versions the current
- version should be incremented as to allow pip to overrite a 0.13 snapshot
- when the next official release.
-
- Please increment and switch the version in setup.py to be a pre-release.
- e.g. 0.13.1a
-
- When a version is tagged it should be changed to a non pre release and then
- in the next commit incremented to the next expected version but with a pre
- release added ::
-
- 0.13.1a -> Head
- 0.13.1 -> when tagged for release
- 0.13.2a -> new head after release
-
- Additionally snapshots can be marked with the .devXXX nomenclature.
-
- These can then all be pushed to pypi.python.org and by default pip will
- install the latest release unless explicitly requested via the ``--pre``
- flag or a version specifier ``docutils>=0.13.1a``
-
.. _Docutils Project Policies: policies.html#version-numbers
.. _Feature Request #50: https://sourceforge.net/p/docutils/feature-requests/50/
.. _PEP 440: https://www.python.org/dev/peps/pep-0440/

engelbert gruber

2017-05-30 11:25:13 UTC

This is how I understood David.

Post by engelbert gruber
this means i should change repository to 0.14rc2.dev ... right ?

If it is not too much work, yes (would allow to install a daily
snapshot over prerelease 0.14.rc1) easily. But it is not urgent IMO.

i only change the numbers and text in the repository: done.

Post by Guenter Milde
May I suggest adding a summary of the discussion to "release.txt"
(patch below, comments and corrections welcome)?

go ahead

Post by Guenter Milde
GÃŒnter
Index: release.txt
===================================================================
--- release.txt (Revision 8090)
+++ release.txt (Arbeitskopie)
@@ -45,36 +45,20 @@
Version numbers shall follow the `Docutils Project Policies`_ and comply
with `PEP 440`_.
-From `Feature Request #50`_
+Especially, mark pre-releases and the repository version/snapshots as
+"between" releases (cf. `Feature Request #50`_ and the discussion on
+docutils-devel on May 28 2017), e.g.
- PEP 440 specifies how release version are understood by pip and other tools.
+| prev. release 0.13.1,
+| prerelease 0.14rc1,
+| [prereleases 0.14rc2, ...]
+| release 0.14,
+| repo/snapshots 0.15.dev
+| [bugfix relases 0.14.1, ...] # branches off of the 0.14 release.
- The last released package of docutils was in 2014.
+The repository version number is always equal to the last released
+version + 1, with a .dev suffix: ``<major>.<minor+1>.dev``.
- If you install the version from Source it will not be overriden by version
- 0.13 when it is eventaully released.
-
- As folks have installed 0.13 from indeterminate source versions the current
- version should be incremented as to allow pip to overrite a 0.13 snapshot
- when the next official release.
-
- Please increment and switch the version in setup.py to be a pre-release.
- e.g. 0.13.1a
-
- When a version is tagged it should be changed to a non pre release and then
- in the next commit incremented to the next expected version but with a pre
-
- 0.13.1a -> Head
- 0.13.1 -> when tagged for release
- 0.13.2a -> new head after release
-
- Additionally snapshots can be marked with the .devXXX nomenclature.
-
- These can then all be pushed to pypi.python.org and by default pip will
- install the latest release unless explicitly requested via the ``--pre``
- flag or a version specifier ``docutils>=0.13.1a``
-
.. _Docutils Project Policies: policies.html#version-numbers
.. _Feature Request #50: https://sourceforge.net/p/
docutils/feature-requests/50/
.. _PEP 440: https://www.python.org/dev/peps/pep-0440/
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
https://lists.sourceforge.net/lists/listinfo/docutils-develop
Please use "Reply All" to reply to the list.

David Goodger

2017-05-28 18:59:27 UTC

Post by David Goodger
* Announce the date of the feature freeze, at least a week away. Just
saying "feature freeze now" is not OK.

I must insist on adding this. We must have a schedule before a feature
freeze, in order to give people (myself included) time to get their
features finished and committed.

I still haven't seen this this time. There was no definite date for a
feature freeze, just "one is coming up soon". I have some features I'm
working on, but there's now a sudden feature freeze. This is not
developer-friendly.

Please add this as a step to the release procedure.

David Goodger
<http://python.net/~goodger>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
Docutils-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-develop

Please use "Reply All" to reply to the list.

engelbert gruber

2017-05-29 12:59:41 UTC

you are free to commit

i do trust people know what they are doing

Post by David Goodger
* Announce the date of the feature freeze, at least a week away. Just
saying "feature freeze now" is not OK.

when do you want to be ready ?

although adding features before a release ?
i personally would wait with "features" for after the release.

all the best

Post by David Goodger
Please add this as a step to the release procedure.
David Goodger
<http://python.net/~goodger>
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
https://lists.sourceforge.net/lists/listinfo/docutils-develop
Please use "Reply All" to reply to the list.

Guenter Milde

2017-05-29 20:31:58 UTC

Dear Engelbert, dear David,

if I understood David right, there are 2 issues:

a) the current situation regarding feature freeze

b) the release procedure rules/conventions.

For b), I suggest

Post by David Goodger
* Announce the date of the feature freeze, at least a week away. Just
saying "feature freeze now" is not OK.

Suggestion:

@@ -100,9 +84,11 @@

* **On the Docutils-develop mailing list, announce that the release is
going to be made, update the release notes and ask for additions.**

Consult HISTORY.TXT for changes.

+* **Announce the date of the feature freeze, at least a week away.**
+
* **Announce a check-in freeze on Docutils-develop.**

* **Announce the upcoming release at the Sphinx-devel mailing list

Günter

engelbert gruber

2017-05-30 11:37:40 UTC

Post by Guenter Milde
a) the current situation regarding feature freeze

i am fine with any way.

but please understand, i am following the commits.
there is not that much activity that discussing a policy seams necessary to
me.

just (as usual) drop me a note

David Goodger

2017-06-01 19:59:22 UTC

On Tue, May 30, 2017 at 6:37 AM, engelbert gruber

Post by Guenter Milde
a) the current situation regarding feature freeze

i am fine with any way.
but please understand, i am following the commits.
there is not that much activity that discussing a policy seams necessary to
me.
just (as usual) drop me a note

While I appreciate your flexibility, this is an odd situation. We have
a feature freeze announced, but no effective dates of the freeze or
the release: no start or end dates on the freeze. The rc1 release
seems to have been done. But we seem to be open to any kind of
commits... It's odd.

Ours is a small project, with few developers. But I think we should
aspire to a greater degree of discipline (breaking APIs, feature
freezes & dates, releases & dates). I'd like to know what the status
of the project is, but it's quite vague at present.

If you look at Python itself, they write an entire PEP for each
release. We're too small to do that, but I think there should be email
to the -dev list that states:

* Release upcoming. OK? Schedule:
* Feature freeze on YYYY-MM-DD [at least one week in the future].
* rc1 on YYYY-MM-DD.
* Final ______ [e.g. one week] later if no significant issues encountered.

Engelbert, thank you again for being our release manager.

David Goodger
<http://python.net/~goodger>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
Docutils-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-develop

Please use "Reply All" to reply to the list.

Guenter Milde

2017-06-01 22:37:32 UTC

Dear David, dear Engelbert,

Post by David Goodger
On Tue, May 30, 2017 at 6:37 AM, engelbert gruber

Post by Guenter Milde
a) the current situation regarding feature freeze

i am fine with any way.
but please understand, i am following the commits. there is not that
much activity that discussing a policy seams necessary to me.
just (as usual) drop me a note

My understanding is, that something went wrong but we are on the way out:

Engelbert announced a "feature freeze" without explicit advance warning
and you objected that citing commits in the pipeline.

To prevent this happening again, we added the rule
**Announce the date of the feature freeze, at least a week away.**
to release.txt

Engelbert also clarified that bugfixes are allowed under the "feature
freeze".

The current situation is still vague:

We don't know whether you plan to include additional features in 0.14 or
if this can wait until 0.15. (Maybe because this depends on the planned
release date?)

I understood Engelberts "i am fine with any way" as readiness to lift
the feature freeze, in case you want additional features in 0.14.

To come out of the deadlock, I would appreciate, if you could tell us:

* Are there new features you want in release 0.14?
(In any case, if it take too long, ...)

* Are there cleanup operations or bug fixes you want in release 0.14?

Post by David Goodger
* Feature freeze on YYYY-MM-DD [at least one week in the future].
* rc1 on YYYY-MM-DD.
* Final ______ [e.g. one week] later if no significant issues encountered.

I agree to the general idea to give dates but can also live with more
"vague" dates (+- a week) in case real life prevents us spare-time
developers from announcing an exact day of release in advance.

Post by David Goodger
Engelbert, thank you again for being our release manager.

Günter

engelbert gruber

2017-06-01 22:59:27 UTC

the status is

rc1 is out and we are waiting for some feedback from sphinx if anything is
broken

rc1 especially is a prerelease so sphinx and whover else is able to test
with a release
and not only with a checkout

if no bugfix commits are allowed, the there is no need for a prerelease.

Post by David Goodger
* Feature freeze on YYYY-MM-DD [at least one week in the future].
* rc1 on YYYY-MM-DD.
* Final ______ [e.g. one week] later if no significant issues encountered.

i do not mind, although i can not guarantee to hold the dates
and for significant issues the release might be stopped anyway.

Post by David Goodger
Dear David, dear Engelbert,

Post by David Goodger
On Tue, May 30, 2017 at 6:37 AM, engelbert gruber

Post by Guenter Milde
a) the current situation regarding feature freeze

i am fine with any way.
but please understand, i am following the commits. there is not that
much activity that discussing a policy seams necessary to me.
just (as usual) drop me a note

Engelbert announced a "feature freeze" without explicit advance warning
and you objected that citing commits in the pipeline.
To prevent this happening again, we added the rule
**Announce the date of the feature freeze, at least a week away.**
to release.txt
Engelbert also clarified that bugfixes are allowed under the "feature
freeze".
We don't know whether you plan to include additional features in 0.14 or
if this can wait until 0.15. (Maybe because this depends on the planned
release date?)
I understood Engelberts "i am fine with any way" as readiness to lift
the feature freeze, in case you want additional features in 0.14.
* Are there new features you want in release 0.14?
(In any case, if it take too long, ...)
* Are there cleanup operations or bug fixes you want in release 0.14?

Post by David Goodger
* Feature freeze on YYYY-MM-DD [at least one week in the future].
* rc1 on YYYY-MM-DD.
* Final ______ [e.g. one week] later if no significant issues

encountered.
I agree to the general idea to give dates but can also live with more
"vague" dates (+- a week) in case real life prevents us spare-time
developers from announcing an exact day of release in advance.

Post by David Goodger
Engelbert, thank you again for being our release manager.

GÃŒnter
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
https://lists.sourceforge.net/lists/listinfo/docutils-develop
Please use "Reply All" to reply to the list.

Komiya Takeshi

2017-06-02 16:38:54 UTC

rc1 especially is a prerelease so sphinx and whover else is able to test with a release

and not only with a checkout

I confirmed all testcases of Sphinx have been passed with 0.14rc1 :-)

Thanks,
Takeshi KOMIYA

the status is
rc1 is out and we are waiting for some feedback from sphinx if anything is
broken
rc1 especially is a prerelease so sphinx and whover else is able to test
with a release
and not only with a checkout
if no bugfix commits are allowed, the there is no need for a prerelease.

Post by David Goodger
* Feature freeze on YYYY-MM-DD [at least one week in the future].
* rc1 on YYYY-MM-DD.
* Final ______ [e.g. one week] later if no significant issues encountered.

i do not mind, although i can not guarantee to hold the dates
and for significant issues the release might be stopped anyway.

Post by David Goodger
Dear David, dear Engelbert,

Post by David Goodger
On Tue, May 30, 2017 at 6:37 AM, engelbert gruber

Post by Guenter Milde
a) the current situation regarding feature freeze

i am fine with any way.
but please understand, i am following the commits. there is not that
much activity that discussing a policy seams necessary to me.
just (as usual) drop me a note

Post by David Goodger
* Feature freeze on YYYY-MM-DD [at least one week in the future].
* rc1 on YYYY-MM-DD.
* Final ______ [e.g. one week] later if no significant issues encountered.

I agree to the general idea to give dates but can also live with more
"vague" dates (+- a week) in case real life prevents us spare-time
developers from announcing an exact day of release in advance.

Post by David Goodger
Engelbert, thank you again for being our release manager.

Günter
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
https://lists.sourceforge.net/lists/listinfo/docutils-develop
Please use "Reply All" to reply to the list.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
https://lists.sourceforge.net/lists/listinfo/docutils-develop
Please use "Reply All" to reply to the list.

engelbert gruber

2017-06-03 10:27:01 UTC

Post by engelbert gruber
rc1 especially is a prerelease so sphinx and whover else is able to test

with a release
and not only with a checkout
I confirmed all testcases of Sphinx have been passed with 0.14rc1 :-)

many thanks

David Goodger

2017-06-01 19:00:25 UTC

Post by Guenter Milde
Dear Engelbert, dear David,
a) the current situation regarding feature freeze
b) the release procedure rules/conventions.
For b), I suggest

[patch to docs/dev/release.txt, below]

+1, thanks for doing that.

David Goodger
<http://python.net/~goodger>