Prepare v0.4 release #339
Prepare v0.4 release #339
Conversation
`.gv` and `.html` files include the version number as a comment. Rebuild to avoid diffs during development
Moved metadata and options info further down, so that the core functionality (connectors, cables, connection sets) comes first.
- Use pin names instead of pin indices, until the last moment when generating the ports for the GraphViz nodes - `Harness.add_mate_pin()` now uses pin names - Remove unused `if is_arrow()` check from `Harness.connect()` - Consolidate calling of `Connector.activate_pin()` to prevent subtle bugs - Call it from `connect()` and `add_mate_pin()` - No longer call it from `create_graph()` - Misc. other tuning
Co-authored-by: kvid <kvid@users.noreply.github.com>
Co-authored-by: kvid <kvid@users.noreply.github.com>
Co-authored-by: kvid <kvid@users.noreply.github.com>
Co-authored-by: kvid <kvid@users.noreply.github.com>
Experiments in exporting PDF using `wkhtmltopdf` utility caused borders to disappear when set to 0.25mm, but 0.35mm renders fine
Re-add `parse_file()` for building examples bla
|
See my bottom question in #309 (comment) where I point out that the code to be released now only lists quite old Python versions in |
|
After thinking a bit, I now believe it's best to leave the supported Python versions unchanged for this release. #251 has already such changes, and we'll get more time testing it after that is merged into |
There was a problem hiding this comment.
I suggest expanding the "Installing the development version" section of README to include recommending venv by, e.g. copying commands from #251 (comment) (checking out the dev branch) and also include pip3 install isort and pip3 install black after activating .venv. It will lower the threshold for potential contributors to have a list of commands to get started.
I don't know if it makes sense to create a requirements-dev.txt like this to simplify the README description:
-r requirements.txt
isort
black
Edit: This task about installation description can of course wait unless you have a sequence of commands ready that you have used yourself and don't need testing.
Co-authored-by: kvid <kvid@users.noreply.github.com>
|
Thank you for your review, I have integrated most suggestions and written a comment on the ones that I didn't.
Agreed.
Good idea, but let's do this after the refactor is merged into Once v0.4 is merged into master and published, I will try to cherry-pick all of your code suggestions (as far as they are still applicable) to the refactored code so we don't suffer a regression there. Since most of the current suggestions are quite minor, would you give the OK for releasing v0.4? Then all further review/suggestion effort can be focused on the newer code. Thanks! |
Remove the references in the CLI help, but keep the placeholders elsewhere in the code as a TODO
|
Thank's for accepting most of my suggestions. Note that I pushed a small commit that you should approve or undo. I think it'll help users with old YAML files to get such a notice instead of something that looks like an internal error. It's also easy to expand this later when more attributes get obsolete or changed. |
|
It's a good idea. Let's see if this can be maintained/updated for future changes; for now it should at least catch the big issues, which is already helpful! |
|
I am traveling and will be able to merge/publish next week. |
There was a problem hiding this comment.
I just discovered two of the new examples have "0 m" as cable quantity in the BOM because of missing cable length attributes. If this is an unintentional error, it's very easy to correct before the release, but It's no big deal to me if you intentionally leave it as it is.
Maybe a waning about each zero cable/bundle length in the harness could be a future feature?
|
Let's leave the examples as they are. |
|
v0.4 is released 🎉 The next step is somehow integrating #251 into |
|
@formatc1702 wrote:
Congratulations! Thank's a lot for your effort.
First, we need to include all the latest commits from the release into After that step, we should rebase the #251 branch on top of the updated |
|
Another alternative would be to cherry pick some changes that went into master but not into dev (such as your latest suggestions), or simply adding the refactored equivalent of the change by hand. I don't think a rebase/merge makes sense since a lot of the changes are not 1:1 applicable to the refactored code anyway. This way, we avoid weird cross-merges as well. |
As proposed, let's release v0.4 before integrating the large PR #251 into the
devbranch.This PR is intended to do a final check before release, to address any inconsistencies.
The obvious one would be to add the release date to the changelog.