-
Notifications
You must be signed in to change notification settings - Fork 227
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Release v0.4.1 #365
Release v0.4.1 #365
Conversation
@formatc1702 - I'm planning a rebase of this branch later today. Please tell me when you are finished merging in here for today, so I don't mess up your changes. |
Thank you for all of this. I have merged some of the simpler bugfixes, feel free to rebase. |
db1e77f
to
ddb2cba
Compare
Thanks. Let's not add more PRs unless they really are hotfixes. Thinks like #371 are already quite deep in feature-creep territory. This one is fine but everything else needs to wait. |
In Windows might OSError(errno=EINVAL) be raised instead of the already catched exceptions in some cases (depending on the Python version). Suggested fix posted by JarrettR in #344 (comment) Co-authored-by: JarrettR <jrainier@gmail.com>
Specify all HTML files under templates folder to be included as package data files.
Symptom reported in #355: Unable to connect an arrow (mate) to pins higher than 1 without failing: ValueError: X is not in list Bug: The code processing mates used a mix of repeated connector look-ups and local connector variables, and one variable was used before it was assigned the correct value. Fix: The local connector variables are now both assigned initially before processing each mate, and used when processing instead of repeated connector look-ups.
Bug: Not all generated dot output could be changed by tweak entries. Seen in #325 (comment) Tweak processing must be the very last dot producing code to enable tweaking any dot output. Fix: Move all other dot producing code above Tweak processing.
The CLI handling code was redesigned for v0.4 and it seems the code to assign a default title from v0.3.1 has been messed up. This bug has not been triggered by build_examples.py due to it seems to call the parse() function differently. The output_name should be used as default title when present. This will fix the #360 bug report.
Resort module import: Co-authored-by: kvid <kvid@users.noreply.github.com>
The project was moved into the new organization 2023-05-30, but old URLs are still working due to automatic redirects by GitHub. #316 (comment)
This will e.g. enable users to replace the SVG diagram with PNG, that is needed as a work-around when the SVG output from Graphviz is not looking good. Suggested as work-around for Graphviz bug in #175 (comment)
This will enable users to replace the SVG diagram with an embedded PNG, that is an improved work-around when the SVG output from Graphviz is not looking good. Suggested as work-around for Graphviz bug in #175 (comment)
Raising TypeError is better than assert. (Black reformatted) Co-authored-by: Andreas Motl <andreas.motl@panodata.org>
In Windows might OSError(errno = None) be raised instead of the already catched exceptions in some cases (depending on the Python version) Fixes #391
A number of such warnings showed up when running e.g. PYTHONWARNINGS=always python build_examples.py PYTHONWARNINGS=always wireviz ../../examples/demo0?.yml See #309 (comment) Fix: All open() calls should be in a "with open() as x" statement to ensure closing the file when exiting the block in any way. Otherwise, use the new file_read_text() or file_write_text() functions to read or write the whole utf-8 text file and closing it.
docs/CHANGELOG.md
Outdated
## [0.4.1] (2024-XX-XX) | ||
|
||
### Improvements to help reported issues | ||
- Explain unexpeced top-level type ([#342](https://github.com/wireviz/WireViz/issues/342), [#383](https://github.com/wireviz/WireViz/pull/383)) | ||
- Add non-empty label to reduce over-sized loops ([#286](https://github.com/wireviz/WireViz/issues/286), [#381](https://github.com/wireviz/WireViz/pull/381)) | ||
- Improve placeholder name consistency ([#377](https://github.com/wireviz/WireViz/issues/377), [#380](https://github.com/wireviz/WireViz/pull/380)) | ||
- Add work-around for Graphviz SVG bug ([#175](https://github.com/wireviz/WireViz/issues/175), [#371](https://github.com/wireviz/WireViz/pull/371)) | ||
|
||
### Bugfixes | ||
|
||
- Avoid ResourceWarning: unclosed file ([#309 (comment)](https://github.com/wireviz/WireViz/pull/309#issuecomment-2170988381), [#395](https://github.com/wireviz/WireViz/pull/395)) | ||
- Catch ValueError and OSError(errno=None) ([#318 (review)](https://github.com/wireviz/WireViz/pull/318#pullrequestreview-1457016602), [#391](https://github.com/wireviz/WireViz/issues/391), [#392](https://github.com/wireviz/WireViz/pull/392)) | ||
- Avoid Graphviz error when hiding all pins ([#257](https://github.com/wireviz/WireViz/issues/257), [#375](https://github.com/wireviz/WireViz/pull/375)) | ||
- Avoid decimal point and trailing zero for integer BOM quantities ([#340](https://github.com/wireviz/WireViz/issues/340), [#374](https://github.com/wireviz/WireViz/pull/374)) | ||
- Update project URL references ([#364](https://github.com/wireviz/WireViz/pull/364)) | ||
- Add missing import of embed_svg_images ([#363](https://github.com/wireviz/WireViz/pull/363)) | ||
- Use correct default title ([#360](https://github.com/wireviz/WireViz/issues/360), [#361](https://github.com/wireviz/WireViz/pull/361)) | ||
- Fix bugs in mate processing ([#355](https://github.com/wireviz/WireViz/issues/355), [#358](https://github.com/wireviz/WireViz/pull/358)) | ||
- Include missing files in published package ([#345](https://github.com/wireviz/WireViz/issues/345), [#347](https://github.com/wireviz/WireViz/pull/347)) | ||
- Catch OSError(errno=EINVAL) ([#344](https://github.com/wireviz/WireViz/issues/344), [#346](https://github.com/wireviz/WireViz/pull/346)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️
Looks like this is pretty much ready. Is it necessary to do interactive rebase? For me, the integration of the bugfixes looks quite clean, and I'm trying to move away a bit from commit history perfectionism ;) The only note I have is: the to-do item "Bump version to v0.4.1-rc" should be "Bump version to v0.4.1" so that the generated examples bear the correct (released) version mark. |
isort==5.11.5
black==23.3.0
I've followed the same procedure as for previous releases. These steps are the last commits within the PR branch before merging into master. PyPI release will follow shortly. |
WireViz v0.4.1 is released on PyPI 🚀 |
@@ -1,6 +1,31 @@ | |||
# Change Log | |||
|
|||
## [0.4](https://github.com/formatc1702/WireViz/tree/v0.4) (2024-05-12) | |||
## [0.4.1] (2024-07-13) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noticed too late that the link to the release is missing
## [0.4.1](https://github.com/formatc1702/WireViz/tree/v0.4.1) (2024-07-13)
but no biggie, can be fixed in next release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@formatc1702 wrote:
Noticed too late that the link to the release is missing
## [0.4.1](https://github.com/formatc1702/WireViz/tree/v0.4.1) (2024-07-13)
Remember not using the old URLs containing your personal user name formatc1702
!
Another thing about the link: Now that you've created release pages for the version tags, should the version links in CHANGELOG point to the code tree for the tag (as today), or should they point to the release page for the tag? https://github.com/wireviz/WireViz/releases/tag/v0.4.1
but no biggie, can be fixed in next release.
True. However, adding a minor commit to master
fixing only such meta-information (not changing any file used by the code) long before creating a new release might also be considered, as far as I can understand, but I also can accept a point of view against that...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but no biggie, can be fixed in next release.
True. However, adding a minor commit to
master
fixing only such meta-information (not changing any file used by the code) long before creating a new release might also be considered, as far as I can understand, but I also can accept a point of view against that...
I agree. The same would apply to the following:
- Create issue templates #387
- Clarify and align SYNTAX and README descriptions #406
- Update deprecated GitHub Actions and add Python versions #408
No code functionality impacted, so no version bump needed.
dev
TODO: other fixes?Issue freezeCHANGELOG
entries (remember to use new URL)isort
&black
on all.py
filesShould we avoid pushing these last steps to this PR branch?No, they should be pushed together just before PR merge intomaster
and creating the release? Anything missing?build_examples.py
and commit generated filesAfter the release:
dev
after or together with Large scale refactoring #251 merge-in to avoid regressions (manage in separate new PR!)To try these fixes before release, this is one method: