Menu
▾
▴
docutils-develop
|
From: Adam T. <aat...@ou...> - 2022-05-23 03:19:42
|
Would it be possible to make a 0.19 release soon? Additionally, should we formally announce the intention to switch the default `html` to `html5` in the 0.19 RELEASE-NOTES? (currently we note that it "may" change, rather than giving any time scale or concrete position). A |
|
From: Guenter M. <mi...@us...> - 2022-05-25 20:08:25
|
On 2022-05-23, Adam Turner wrote: > Would it be possible to make a 0.19 release soon? I am in favour. Engelbert? However, first I'd like to see a solution for the following problem: There is an emerging consensus, that after 1.0 we want to follow "semantic versioning": no incompatible changes to the API in minor releases. https://sourceforge.net/p/docutils/feature-requests/89/ Currently, several incompatible changes and removals are scheduled for the `minor` releases 1.1, 1.2, and 1.3. This was done under the assumption that 1.0 will be released soon (after 0.18 or 0.19) and following the policy of warnings at least two minor releases before the actual change (as in :PEP:`387`). Alternatives: a) Postpone the removals and changes to version 2.0. +1 No surprises. -1 Junk code and use of deprecated "optparse" module in 1.x series. b) Pre-pone the changes to release 1.0 (after releases 0.19 and 0.20 to keep the "two minor releases" warning period). +1 Cleaner code in Docutils 1.0 -1 Incompatible changes in a "lower" release than currently announced. c) Keep an exception from `semantic versioning` for the 1.x series. +1 Stick to the current announcment. -1 Incompatible change in minor release may be unexpected for some despite beeing documented. ("Special cases aren't special enough to break the rules.") I currently prefer a) as the alternative with smallest "surprise factor". * * * > Additionally, should we formally announce the intention to switch the > default `html` to `html5` in the 0.19 RELEASE-NOTES? (currently we note > that it "may" change, rather than giving any time scale or concrete > position). As author of the `html5` writer I abstain from voting on this topic. Günter |
|
From: Adam T. <aat...@ou...> - 2022-05-26 01:20:53
|
> Currently, several incompatible changes and removals are scheduled > for the `minor` releases 1.1, 1.2, and 1.3. > This was done under the assumption that 1.0 will be released soon > (after 0.18 or 0.19) and following the policy of warnings at least > two minor releases before the actual change (as in :PEP:`387`). [snip] > I currently prefer a) as the alternative with smallest "surprise factor". Postponing removals until 2.0 is probably the most pragmatic approach here (concurring with Günter on option (a)). A |
|
From: Adam T. <aat...@ou...> - 2022-05-30 10:06:28
|
> Postponing removals until 2.0 is probably the most pragmatic approach here (concurring with Günter on option (a)). Two patches are attached that postpone the deprecations to 2.0 and announce the change in default HTML writer. A |
|
From: Guenter M. <mi...@us...> - 2022-05-30 21:29:33
|
On 2022-05-30, Adam Turner wrote: > Two patches are attached that postpone the deprecations to 2.0 and > announce the change in default HTML writer. Thanks. The postponement is now [r9062]. The default "html" writer change is still open/undecided (no problem in 0.19 if envisaged for 2.0). This means we should be clear for release 0.19b. Günter |
|
From: Adam T. <aat...@ou...> - 2022-06-11 00:34:10
|
Dear Engelbert, [Günter] > The default "html" writer change is still open/undecided > (no problem in 0.19 if envisaged for 2.0). > This means we should be clear for release 0.19b. Are you in favour of making a 0.19.0b1 release? The only potential unresolved items are: * announcing a date for the switch to HTML5-by-default (Günter has abstained, I am in favour of announcing the date as 2.0) * bugs#450 [1]_ On the latter, Günter and I have converged towards a single similar patch, so that will hopefully be resolved soon. On the former, I think you would be the casting vote! Please let me know your thoughts, Thanks, Adam _[1]: https://sourceforge.net/p/docutils/bugs/450/ |
|
From: engelbert g. <eng...@gm...> - 2022-06-12 17:45:37
|
Hello Adam, yes I am for rolling 0.19 out maybe I am able to ship 0.19.0b1 on tuesday (tuesday is release day) june 14 or waiting for 450 on 21. two weeks later 0.19 the switch to html5 with 2.0 IMHO is good ... i see no reason to rush it thanks and cheers e On Sat, 11 Jun 2022 at 02:33, Adam Turner <aat...@ou...> wrote: > Dear Engelbert, > > [Günter] > > The default "html" writer change is still open/undecided > > (no problem in 0.19 if envisaged for 2.0). > > > This means we should be clear for release 0.19b. > > Are you in favour of making a 0.19.0b1 release? The only potential > unresolved items are: > > * announcing a date for the switch to HTML5-by-default (Günter has > abstained, I am in favour of announcing the date as 2.0) > * bugs#450 [1]_ > > On the latter, Günter and I have converged towards a single similar patch, > so that will hopefully be resolved soon. On the former, I think you would > be the casting vote! > > Please let me know your thoughts, > Thanks, > Adam > > _[1]: https://sourceforge.net/p/docutils/bugs/450/ > |
|
From: Adam T. <aat...@ou...> - 2022-06-12 18:24:45
|
> maybe I am able to ship 0.19.0b1 on tuesday (tuesday is release day) june 14 > or waiting for 450 on 21. Brilliant, thanks Engelbert! I will wait for Günter's response on bugs#450, but probably the 21st is the best option, with 0.19.0 final then released on 05/07. > the switch to html5 with 2.0 IMHO is good ... i see no reason to rush it OK, I have prepared a patch (attached). No-one has spoken against the change in principle as far as I've been able to tell, and 2.0 should be a good amount of headroom. Sphinx and Nikola are unaffected as they both already use HTML 5 by default. A |
|
From: Guenter M. <mi...@us...> - 2022-06-13 20:43:37
|
On 2022-06-12, Adam Turner wrote: >> maybe I am able to ship 0.19.0b1 on tuesday (tuesday is release day) The first in a series of beta releases should be release level = "beta", serial = 0, release = True. https://docutils.sourceforge.io/docs/dev/policies.html#docutils-version The upcoming release would then have ``__version__ = '0.19b'`` (or "0.19.0b0") rsp. ``__version_info__ = (0, 19, 0, 'beta', 0, True)``. >> june 14 or waiting for 450 on 21. > Brilliant, thanks Engelbert! I will wait for Günter's response on > bugs#450, but probably the 21st is the best option, The last patch for the problem described in bug #450 is "minimally invasive" but still an incompatible API change. https://sourceforge.net/p/docutils/bugs/450/#937a/460a/81bc/e203/ecc3/c6b8 I am still unsure whether curing an announced incompatible API change with an unannounced one is the right way. I would prefer announcing in 0.19 and changing in 0.20 but can also live with an unannounced fix, if this is considered the lesser evil. (We still don't know, whether the fix would satisfy the OP.) > with 0.19.0 final then released on 05/07. We have done some large changes and some removals, so maybe a longer beta period is appropriate... Günter |
|
From: Adam T. <aat...@ou...> - 2022-06-13 21:03:56
|
> The last patch for the problem described in bug #450 is "minimally invasive" > but still an incompatible API change. > https://sourceforge.net/p/docutils/bugs/450/#937a/460a/81bc/e203/ecc3/c6b8 > I am still unsure whether curing an announced incompatible API change > with an unannounced one is the right way. > I would prefer announcing in 0.19 and changing in 0.20 but can also live > with an unannounced fix, if this is considered the lesser evil. I would argue the latter, that it is better to have the fix released. For users who just use the default stylesheets, the fix will be automatic as we've fixed the stylesheets. For users who use a downstream framework (e.g. Sphinx) there will be no immediate effect as those frameworks put an upper bound on their Docutils version. The class of affected users I can think of is those users who use Docutils directly with custom stylesheets -- and I think for this class of users the benefit of better control of styling outweighs the minor annoyance of (potentially) updating some CSS -- as we see from the latest patch the changes required are small. Whilst not ideal therefore, I vote for including the patch in 0.19.0b0. > (We still don't know, whether the fix would satisfy the OP.) I have asked Pradyun on the issue to respond. > > with 0.19.0 final then released on 05/07. > We have done some large changes and some removals, > so maybe a longer beta period is appropriate... We do beta releases for Sphinx and very few people ever test them. We got one bug report for the 5.0.0 beta release and then over ten for when we released 5.0.0 final. Pragmatically, I think we should stick to the standard schedule, and just be prepared to deal with bug fixes as and when needed. A |
|
From: Guenter M. <mi...@us...> - 2022-06-14 16:10:40
|
On 2022-06-12, engelbert gruber wrote: > yes I am for rolling 0.19 out > maybe I am able to ship 0.19.0b1 on tuesday (tuesday is release day) june 14 > or waiting for 450 on 21. I suggest June 21th, so we can agree on the optimal approach regarding HTML5 footnotes and give it some road testing. Thanks, Günter |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X