-
Notifications
You must be signed in to change notification settings - Fork 201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release Notes #1773
Comments
Version 2.0.0
|
Version 2.1.0
|
Version 2.3.0Whoops, didn't write release notes for the 2.2 versions! Oh well!
|
Version 2.3.1
Version 2.4.0
|
Version 2.4.1
|
Version 2.4.2
Version 2.4.3
|
lol been skipping release notes for a while! Version 2.4.4
Version 2.4.5
Version 2.4.6
Version 2.4.7
Version 3.0.0
Version 3.0.1
Version 3.0.2
Version 3.0.3
Version 3.0.4
Version 3.0.5
Version 3.0.6
Version 3.1.0
Version 3.2.0
Version 3.3.0Big new WPT features - inline test results!
And some other random stuff:
Version 3.3.1
Version 3.3.2
Version 3.3.3
Version 3.3.4
Version 3.4.0
|
Version
|
Version 3.5.0
Version 3.5.1
Version 3.5.2
|
Version 3.6
Version 3.7
|
Been a while since my last batch of release notes! Version 3.7.1
Version 3.7.2
Version 3.7.3
Version 3.7.4
Version 3.7.5
Version 3.7.6
Version 3.7.7
Version 3.8.0
Version 3.8.1
Version 3.8.2
Version 3.9.0
|
New big batch of release notes: Version 3.10.0
Version 3.10.1
Version 3.11.0
Version 3.11.1
Version 3.11.2 & 3.11.3
Version 3.11.4
Version 3.11.5
Version 3.11.6
Version 3.11.7
Version 3.11.8
Version 3.11.9
Version 3.11.10
Version 3.11.11
Version 3.11.12
Version 3.11.13
Version 3.11.14
Version 3.11.15
Version 3.11.16
|
Version 3.11.17Turns out using just a little of a new HTML parser causes problems when my old hacky line-based code is, well, doing things line-by-line, and thus only feeding the parser part of a tag when a tag is split across multiple lines. So now I just use the HTML parser for the entire pre-Markdown parsing pipeline. (Then Markdown runs, generates some HTML, and feeds its result straight to the lxml parser. Both of these will be rewritten in time as well.) It looks like this doesn't cause any issues with the testsuite, and hopefully should resolve the spurious fatal errors that 3.11.16 was throwing. Lmk if you see any issues! |
Version 3.11.18 - 3.11.21
Post-MortemSo, 3.11.14 caused some problems. I was throwing my new HTML parser at my At this point I could have reverted the code and worked on it more in a branch, and should have. (Second mistake.) Instead I dug in - my new code was nicer, and I wanted to replace all my hacky text munging anyway, so I might as well just rip it out entirely and use my new parser. This took a few days, but it was productive work, and I was happy with it. I did this via a big chain of "wip" commits, with test rebasing going on arbitrarily in commits, so when I thought I was done, I did a big squash commit - Takeaway Fixes
|
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Version 3.11.22
Version 3.11.23
Version 3.12.0
Version 3.12.1
Version 3.13.0
|
Version 3.14.0Let's try that HTML parser rewrite again! Coming at it more gradually now; I do one early pass over the document with the new parser and then just reserialize back to a string. I haven't yet replaced the datablock, markdown, or shorthand parsing, and I still pass it to the pre-existing HTML parser to actually build a tree, so mostly this is just some extra work being done, but those'll all be absorbed into this work in later phases. As I say in #2602, this brings a few benefits immediately:
It then still runs the datablock, markdown, and finally the existing HTML parser over the spec, so this is probably slightly slower at the moment, but those will be eaten by the parser in later phases. Known issues with existing specs' markup: If you were working around the hacky The HTML parser runs before the Markdown parser right now Previously, The Markdown behavior of "if you have spaces at both the start and end of a code span, remove one from each side" is now properly implemented. A few specs relied on it removing any amount of any whitespace, so now there's an extra space sometimes if you did a linebreak inside your code span for some reason. |
A few small updates in the last few weeks. Version 3.14.1
Version 3.14.2
Version 3.14.3
Version 3.14.4
|
Version 3.14.5
|
Version 4.0.0Woo, major version bump! Content-wise this isn't a break-worthy update, but Bikeshed has officially deprecated support for Python 3.7 (and 3.8), and now requires a minimum version of 3.9. As far as I can tell, this is the highest widely-supported version among default installs now; the old OSes that bundled 3.7 by default are all now out of long-term support.
Most of my time was spent on making Bikeshed's new HTML parser more powerful and more correct (mostly in 5c6f7af). This shouldn't have any big effect on you (some caveats, below), but every step forward I make here makes me so much happier.
I did a lot of careful test review to make sure things are as correct as possible. Aside from the bits I listed above, and the possibility of some new markup errors being flagged, |
Version 4.0.1
|
Version 4.0.2
Version 4.0.3
Neither of these should actually affect specs in a user-observable fashion; let me know if anything seems to be newly wrong. |
Version 4.1.0Several miscellaneous fixes; I wanna get these out before I dive back into the parser.
|
Version 4.1.1A few small fixes.
|
Version 4.1.3
|
Version 4.1.4
|
Version 4.1.5Tiny release.
Version 4.1.6
|
Version 4.1.7 & 4.1.8(4.1.7 was an accidental no-op release.) Tiny update!
|
Whoops, left a few version off the changelist. They're all minor except the last. Version 4.1.9
Version 4.1.10
Version 4.1.11
Version 4.1.12
Version 4.2.0
|
Version 4.2.2
Version 4.2.3
Version 4.2.4
Version 4.2.5 - 4.2.7Insignificant version bumps, just me trying to get py.typed included, so mypy knows about Bikeshed's types. Version 4.2.8
|
Version 5.0.0Big version bump this time, because it's a big update. This release includes the ~200 commits making up the new Big Parser Upgrade, which moves all of Bikeshed's "inline" special syntax (macros, link shorthand syntax like Before I get into the implications of that, there's a few other misc fixes that got into this release:
Parser UpdatesAs I said, back in July 2023 I released version 3.14, with a new hand-written HTML parser. (There were some preceding releases that tried to use an earlier version of this parser, but 3.14 was the big one.) At the time the main effect of this was that I finally got accurate source-location information for all tags, something which was sorely lacking from my existing HTML parser. This update expands the parser to handle all inline Bikeshed syntax. (That is, not block-level Markdown stuff like lists/etc.) Previously, these were handled by several distinct passes over the document at different times:
As a result of these happening in several phases, escaping was complicated and inconsistent, depending on whether they were processed before or after the HTML parser ran. For example, Also, because these were done via regexes, I didn't really have source location information anymore. The best I could do was sometimes report the line of the nearest element created by the Markdown block parser, which did know exactly what line of the source everything it created was from. Now, the bespoke parser handles all of these consistently, at the same time. I know the precise source location of every inline construct; escapes are handled in a consistent manner for everything; etc. As part of this, I also needed to start tracking the open elements, so I know whether I'm in an element that should suppress shorthands or not. This means I'm suddenly able to detect errors in tag nesting, missing end tags, or misspelled end tags, which seem to be reasonably common in practice. Implications
If you see any problems, please let me know. The code has been live for about two weeks so far and it seems like it's generally been a smooth transition. Version 5.0.1
5.0.1 is largely a perf release. I plan to try and get HTML converted to Bikeshed later this year, and needed to make sure that it could handle a document of that size. To do this, I just made a spec that was 15 copies of the DOM spec appended to itself, approximately the same filesize as the HTML source. First try, with the 5.0.0 code, took 7s to process the original DOM source, and 770 seconds (13min and change) to do the 15-doms spec. That was ridiculous, clearly I had some quadratic behavior. After a bunch of honestly pretty easy fixes, 15-doms is down to 70s, and DOM itself is down to 5s. I have some evidence that the fixes might have slightly slowed down small specs (the testsuite seems to be a few seconds slower), but they're already fast enough that it seems insignificant. Version 5.0.2Tiny bump because I'd merged a PR and failed to merge it into 5.0.1 before making the release.
|
(This thread documents the updates in comments; this original comment always reflects the latest version.)
Version 5.0.0
Big version bump this time, because it's a big update. This release includes the ~200 commits making up the new Big Parser Upgrade, which moves all of Bikeshed's "inline" special syntax (macros, link shorthand syntax like
[=...=]
, inline Markdown) into the bespoke HTML parser first introduced back in Version 3.14.Before I get into the implications of that, there's a few other misc fixes that got into this release:
Parser Updates
As I said, back in July 2023 I released version 3.14, with a new hand-written HTML parser. (There were some preceding releases that tried to use an earlier version of this parser, but 3.14 was the big one.) At the time the main effect of this was that I finally got accurate source-location information for all tags, something which was sorely lacking from my existing HTML parser.
This update expands the parser to handle all inline Bikeshed syntax. (That is, not block-level Markdown stuff like lists/etc.) Previously, these were handled by several distinct passes over the document at different times:
[FOO]
) were done as a regex over the original source<<foo>>
and''foo''
autolinks - the former because they wouldn't survive a normal HTML parse, the second because they often contained additional markup, and that broke things in later passesAs a result of these happening in several phases, escaping was complicated and inconsistent, depending on whether they were processed before or after the HTML parser ran. For example,
[FOO]
would successfully escape a macro, keeping it as a plain[FOO]
text in your document (because the macro parser ran before the HTML parser), but[=foo=]
would not escape a dfn autolink; the HTML parser would canonicalize the escape back into a[
before the shorthand parser got a chance to run.Also, because these were done via regexes, I didn't really have source location information anymore. The best I could do was sometimes report the line of the nearest element created by the Markdown block parser, which did know exactly what line of the source everything it created was from.
Now, the bespoke parser handles all of these consistently, at the same time. I know the precise source location of every inline construct; escapes are handled in a consistent manner for everything; etc.
As part of this, I also needed to start tracking the open elements, so I know whether I'm in an element that should suppress shorthands or not. This means I'm suddenly able to detect errors in tag nesting, missing end tags, or misspelled end tags, which seem to be reasonably common in practice.
Implications
\[
to escape macros in<script>
or similar, you no longer need to (and the\
will now be left in your document, probably causing an error).[FOO](/foo)
). You could previously write\[FOO](/foo)
to escape it at the macro-processing time, which would remove the\
, so at inline-markdown processing time it saw just the markdown link markup. This is no longer necessary, since both are handled at the same time -[FOO](/foo)
will be recognized as a markdown link properly, not a macro. (And the escaped version will produce an escaped markdown link now, aka plain text with []s.)If you see any problems, please let me know. The code has been live for about two weeks so far and it seems like it's generally been a smooth transition.
Version 5.0.1
|arg|: description
lines in argumentdef blocks. This is now manually handled.5.0.1 is largely a perf release. I plan to try and get HTML converted to Bikeshed later this year, and needed to make sure that it could handle a document of that size. To do this, I just made a spec that was 15 copies of the DOM spec appended to itself, approximately the same filesize as the HTML source.
First try, with the 5.0.0 code, took 7s to process the original DOM source, and 770 seconds (13min and change) to do the 15-doms spec. That was ridiculous, clearly I had some quadratic behavior.
After a bunch of honestly pretty easy fixes, 15-doms is down to 70s, and DOM itself is down to 5s. I have some evidence that the fixes might have slightly slowed down small specs (the testsuite seems to be a few seconds slower), but they're already fast enough that it seems insignificant.
Version 5.0.2
Tiny bump because I'd merged a PR and failed to merge it into 5.0.1 before making the release.
bikeshed serve
, the message now gives a full localhost url rather than just listing the port, so you can click it and open a tab.The text was updated successfully, but these errors were encountered: