You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've created a new milestone to show which features I'd like to have included in the next release, i.e. pushing to master as well as uploading the new package to PyPI.
If anybody wants to suggest more issues to include, please let me know. However, my aim is to release v0.2 relatively soon, which is why I've deliberately left out a lot of existing requests.
Uptate on the v0.2 milestone:
I've assigned people for most open issues/PRs, hoping to be able to assign #114 soon too. If anybody wants to take on #60, please comment there and I will asign you.
Additionally, I've made a milestone for v0.3, which currently only serves to denote issues/PR drafts that I know I want to pursue as soon as v0.2 is out, but not before.
Just a quick FYI especially for @kvid, I'll be taking a couple of days off coding to breathe a bit, and I promise I shall be back to read through all the comments, commits and other contributions as usual.
It will help me get back my focus and ensure v0.2 gets released with no major issues :)
"Perfect is the enemy of the good", so let's get this release out soon and hopefully receive feedback on the new features. I suggest that after the release, we can decide on prioritizing the upcoming issues to get another cool set of features for v0.3!
Thanks everybody who's contributed so far, with major kudos to @kvid for submitting good PRs and doing some thorough code review!
Unforeseen circumstances prevented me from working on WireViz this week, so the v0.2 release will have to wait another 2-3 weeks until after my holidays 😐 oh well...
Here's a quick update for everyone, especially for @kvid, @Tyler-Ward, @martonmiklos, @zombielinux [and others?] who have submitted contributions while I was gone. Thanks a lot for your continued support, and interest in this project!
I hope to resume reviewing/merging/coding in the upcoming weeks, so don't worry, this project is not forgotten!
Holidays, personal and work related issues have kept me busy and delayed things quite a bit... I will get back to every single issue and PR and integrate them into the project one by one as I find time to keep working on WireViz. I need a few more days to be able to continue, but rest assured, I am looking forward to integrate new features and get new releases out the door!
Cheers!
Reacted by Miklós Márton, Tyler Ward, kvid and Steve Traugott
When the PRs are ready and unless rejected by @formatc1702 , I suggest he merge them into dev in this order: #115, #164, #163, #153, and #111, but please give the PR authors a couple of days for rebasing on top of the new dev and resolving conflicts before each merge.
Thanks for the suggestion. I haven't looked at the contributions in detail; just one question:
Why not prioritize #153 and #111, which were planned for v0.2 already, get that one released, and then continue with the other PRs you mention? I'm worried that the v0.2 release will be further delayed if we try to include every new addition, and it might be better to make a clean cut between what goes into v0.2, and what will go into v0.3 and beyond.
If there's a technical reason that would prevent this, please let me know. Thanks!
I would like to go forward with merging #332 and #298 into dev, publishing v0.4 and afterwards immediately rebasing big-refactor onto dev and fast-fowarding, so finally we have a dev branch with more manageable PRs again.
I have merged #332 and #298, updated the version number and added a v0.4-rc tag.
[Edit 2024-05-05]: Renamed tag to v0.4-rc to distinguish from proper v0.4 once it is merged into master.
However, I consider this an interim version that will not be merged into master or published on PyPI, and the changelog reflects this.
The next immediate step is rebasing #251 onto the latest dev branch, now labeled v0.5-dev to allow differentiating between changes from before (v0.4) and after (v0.5) the refactoring. I would appreciate any help in doing so. Then dev can be moved forward to contain the refactored code to finally get rid of big-refactor even if not all kinks are fully ironed out yet.
I have merged #332 and #298, updated the version number and added a v0.4 tag.
Thank you!
However, I consider this an interim version that will not be merged into master or published on PyPI, and the changelog reflects this.
I don't understand why v0.4 should not be merged into master and released the normal way. My main motivation for suggesting v0.4 before merging #251 was to make it available to users and getting more usage feed-back.
It shouldn't be much work taking this remaining step to a full release, and I see no drawbacks about it, unless you know about any critical bugs or documentation flaws in v0.4.
The next immediate step is rebasing #251 onto the latest dev branch, now labeled v0.5-dev to allow differentiating between changes from before (v0.4) and after (v0.5) the refactoring. I would appreciate any help in doing so. Then dev can be moved forward to contain the refactored code to finally get rid of big-refactor even if not all kinks are fully ironed out yet.
I agree to this step, but AFTER a merge of v0.4 into master.
@kvid@formatc1702
I see so many feature requests and I would even have some more ideas... It seems overwhelming and possibly requires some priorisation or roadmapping.
I suggest that one of you starts an issue for discussion on this topic. Similar to #365, there should be some PR about the next major release already. I do not want to take ownership of it, though. ;)
It is not obvious, which PRs should be based on master or dev. I noticed that PR #357 is based on the dev branch. The others are merged into a release branch that is directly based on master. If I am to prepare some PR, what shall be the base?
I use #365 to collect simple bugfixes to be released soon, and I have chosen to base such PRs on master to enable other PRs (not part of the upcoming bugfix release) being based on dev in parallel. The next PR to be merged into dev is #251, but I've been too busy lately to look into that yet.
However, it's normally trivial to rebase a PR branch from dev to master or vice versa (unless the amount of change conflicts is huge) if priorities are changed. We are all free to argue for which PRs to include in a release, and if you feel e.g. PR #357 is important to release before a future v0.5, then please describe your reasons for that in a comment. 😃
Normally, I recommend basing a new PR on dev, but if it's a bugfix or other minor change with high priority, then you probably should argue for basing it on master.
I use #365 to collect simple bugfixes to be released soon, and I have chosen to base such PRs on master to enable other PRs (not part of the upcoming bugfix release) being based on dev in parallel. The next PR to be merged into dev is #251, but I've been too busy lately to look into that yet.
Dito. I get the impression, #251 would definitely demand an 0.5 release branch or even a major step to 1.0...
I would love to see semantic-release in action by then. There is a python-specific version called python-semantic-release...
We are all free to argue for which PRs to include in a release, and if you feel e.g. PR #357 is important to release before a future v0.5, then please describe your reasons for that in a comment. 😃
That is the reason why Semantic Versioning states clear rules and leaves out the personal feelings. If we were to follow these, #357 is a feature that would be part of 0.5.
Normally, I recommend basing a new PR on dev, but if it's a bugfix or other minor change with high priority, then you probably should argue for basing it on master.
The special keywords in a pull request description are interpreted when the pull request targets the repository's default branch. However, if the PR's base is any other branch, then these keywords are ignored, no links are created and merging the PR has no effect on the issues. If you want to link a pull request to an issue using a keyword, the PR must be on the default branch.
Note that I do not intend to influence the way that you have been working on this project. I am just giving hints on what could be improved. As long as you can handle things manually and there is no disagreement amongst the collaborators, just keep going without semantic-release. It simplifies and automates some chores, but it also adds dependencies, complexity and thereby limits the freedom that an innovative project needs in early stages!
My actual intent was only to ask for a list of feature priorities for the next release, possibly discussed in a dedicated issue! If you think that this issue is the right place to discuss this, then I am also fine with it.
EDIT: I found this #320 (comment) by coincidence, asking for help on untangling #251 commits.
Even though I have not been able to contribute to the project for a while, it will be nice to share this tool and connect with other hardware nerds. If you happen to at the event as well, feel free to ping me (e-mail preferred)!
And again, thank you everyone for keeping the ball rolling... ❤
Quick heads up: I'm updating my user handle across various platforms*, and this includes GitHub. Sorry if this causes some confusion. This project/repo should not be affected. Some old @ mentions may no longer work, but nothing big should break.
The refactored code has been merged into dev via #447 , a compacted version of #251. The internal version has been bumped from v0.5-dev to v0.5-dev+refactor, based on PEP 440.
Regarding semantic versioning, IMHO it becomes extremely important once you have a "stable" v1, and need to clearly distinguish between breaking and non-breaking changes. At v0.x, I consider the code to be in flux and reserve the right to fully break backwards compatibility for the sake of improving and maturing the codebase. See the note that has been in the Readme forever ;)
This is very much a work in progress. Source code, API, syntax and functionality may change wildly at any time.
I look forward to reaching a point where we can talk about a true v1, but that's not today. Inkscape also took its sweet time and there's nothing wrong with that.
The refactored code has been merged into dev via #447 , a compacted version of #251. The internal version has been bumped from v0.5-dev to v0.5-dev+refactor, based on PEP 440.
Great news!
I've been on travel, and haven't been able to follow up much since I found the solution to #441, verified #443, and created #445 in February.
Regarding semantic versioning, IMHO it becomes extremely important once you have a "stable" v1, and need to clearly distinguish between breaking and non-breaking changes. At v0.x, I consider the code to be in flux and reserve the right to fully break backwards compatibility for the sake of improving and maturing the codebase. See the note that has been in the Readme forever ;)
This is very much a work in progress. Source code, API, syntax and functionality may change wildly at any time.
I look forward to reaching a point where we can talk about a true v1, but that's not today. Inkscape also took its sweet time and there's nothing wrong with that.
I agree...
Do you know if anyone recorded your talk at FOSDEM 2025? I would be glad to see it.
Do you know if anyone recorded your talk at FOSDEM 2025? I would be glad to see it.
The talks were recorded, and I received a link to review the video. It had some gaps (technical issues, probably), so I reported it. I guess it should be released once it's fixed, or once it's clear that the missing bits are gone for good. They were not massive dealbreakers. It should then appear on the talk page itself.
Please consider my suggested way to merge as described in #408 (comment) with hight priority, or suggest alternatives.
@kvid: Apologies for missing this. @17o2: Nice that you gave a talk at FOSDEM. I am looking forward to watch the video when I get back to better connectivity. @amotl: Note to self: It looks like wireviz-web needs a few updates to accompany more recent releases of WireViz. FYI: We also just updated wireviz-web and released version 0.4.2, which uses the latest WireViz 0.4.1.
Thank you everyone for your excellent work on WireViz.
@17o2 and @amotl :
To avoid users loosing faith in our project, I suggest publishing a new release with small changes that are easy to merge into dev for v0.5 later. See my preparations in PR #500.
I was not able to find the video from FOSDEM - if anyone found it, please provide a link here.
Activity
17o2 commentedon Jul 19, 2020
I've created a new milestone to show which features I'd like to have included in the next release, i.e. pushing to
masteras well as uploading the new package to PyPI.If anybody wants to suggest more issues to include, please let me know. However, my aim is to release v0.2 relatively soon, which is why I've deliberately left out a lot of existing requests.
17o2 commentedon Jul 21, 2020
Uptate on the v0.2 milestone:
I've assigned people for most open issues/PRs, hoping to be able to assign #114 soon too. If anybody wants to take on #60, please comment there and I will asign you.
Additionally, I've made a milestone for v0.3, which currently only serves to denote issues/PR drafts that I know I want to pursue as soon as v0.2 is out, but not before.
kvid commentedon Jul 24, 2020
Have you considered #116 and #121 for the v0.2 milestone?
17o2 commentedon Jul 24, 2020
Added both! Thanks.
kvid commentedon Aug 1, 2020
I just made a suggestion in the closed issue #122 (comment). Do you think it should be reopened?
17o2 commentedon Aug 1, 2020
Feel free to do so!
kvid commentedon Aug 1, 2020
I don't know how. Maybe I'm not authorized to do it.
17o2 commentedon Aug 1, 2020
Not sure.. did it myself now :)
Perhaps only repo owners (and maybe the original commenter) have the "reopen issue" button...
kvid commentedon Aug 1, 2020
Thank's
You are right. I certainly did not see that button here, but I can see it in one of the closed issues I opened myself.
17o2 commentedon Aug 4, 2020
Just a quick FYI especially for @kvid, I'll be taking a couple of days off coding to breathe a bit, and I promise I shall be back to read through all the comments, commits and other contributions as usual.
It will help me get back my focus and ensure v0.2 gets released with no major issues :)
17o2 commentedon Aug 17, 2020
My goal is to get v0.2 released by the end of the week.
I'm assuming this is due to the holiday period and I hope the authors make a comeback at some point :)
Otherwise, I'm sure us other contributors will find a way to work on this while keeping the authorship intact.
"Perfect is the enemy of the good", so let's get this release out soon and hopefully receive feedback on the new features. I suggest that after the release, we can decide on prioritizing the upcoming issues to get another cool set of features for v0.3!
Thanks everybody who's contributed so far, with major kudos to @kvid for submitting good PRs and doing some thorough code review!
17o2 commentedon Aug 22, 2020
Unforeseen circumstances prevented me from working on WireViz this week, so the v0.2 release will have to wait another 2-3 weeks until after my holidays 😐 oh well...
17o2 commentedon Sep 24, 2020
Here's a quick update for everyone, especially for @kvid, @Tyler-Ward, @martonmiklos, @zombielinux [and others?] who have submitted contributions while I was gone. Thanks a lot for your continued support, and interest in this project!
I hope to resume reviewing/merging/coding in the upcoming weeks, so don't worry, this project is not forgotten!
Holidays, personal and work related issues have kept me busy and delayed things quite a bit... I will get back to every single issue and PR and integrate them into the project one by one as I find time to keep working on WireViz. I need a few more days to be able to continue, but rest assured, I am looking forward to integrate new features and get new releases out the door!
Cheers!
kvid commentedon Oct 4, 2020
When the PRs are ready and unless rejected by @formatc1702 , I suggest he merge them into
devin this order: #115, #164, #163, #153, and #111, but please give the PR authors a couple of days for rebasing on top of the newdevand resolving conflicts before each merge.17o2 commentedon Oct 5, 2020
Thanks for the suggestion. I haven't looked at the contributions in detail; just one question:
Why not prioritize #153 and #111, which were planned for v0.2 already, get that one released, and then continue with the other PRs you mention? I'm worried that the v0.2 release will be further delayed if we try to include every new addition, and it might be better to make a clean cut between what goes into v0.2, and what will go into v0.3 and beyond.
If there's a technical reason that would prevent this, please let me know. Thanks!
34 remaining items
kvid commentedon Jan 21, 2024
IMHO, we need to fix #328 before a new release. Please comment my suggested fix with a new option in that issue.
17o2 commentedon Apr 16, 2024
I have submitted #332 as a response to #328.
I would like to go forward with merging #332 and #298 into
dev, publishing v0.4 and afterwards immediately rebasingbig-refactorontodevand fast-fowarding, so finally we have adevbranch with more manageable PRs again.17o2 commentedon Apr 16, 2024
I have merged #332 and #298, updated the version number and added a
v0.4-rctag.[Edit 2024-05-05]: Renamed tag to
v0.4-rcto distinguish from properv0.4once it is merged into master.However, I consider this an interim version that will not be merged into master or published on PyPI, and the changelog reflects this.
The next immediate step is rebasing #251 onto the latest
devbranch, now labeledv0.5-devto allow differentiating between changes from before (v0.4) and after (v0.5) the refactoring. I would appreciate any help in doing so. Thendevcan be moved forward to contain the refactored code to finally get rid ofbig-refactoreven if not all kinks are fully ironed out yet.kvid commentedon Apr 25, 2024
Thank you!
I don't understand why v0.4 should not be merged into master and released the normal way. My main motivation for suggesting v0.4 before merging #251 was to make it available to users and getting more usage feed-back.
It shouldn't be much work taking this remaining step to a full release, and I see no drawbacks about it, unless you know about any critical bugs or documentation flaws in v0.4.
I agree to this step, but AFTER a merge of v0.4 into master.
martinrieder commentedon Jun 8, 2024
@kvid @formatc1702
I see so many feature requests and I would even have some more ideas... It seems overwhelming and possibly requires some priorisation or roadmapping.
I suggest that one of you starts an issue for discussion on this topic. Similar to #365, there should be some PR about the next major release already. I do not want to take ownership of it, though. ;)
It is not obvious, which PRs should be based on
masterordev. I noticed that PR #357 is based on thedevbranch. The others are merged into a release branch that is directly based onmaster. If I am to prepare some PR, what shall be the base?kvid commentedon Jun 8, 2024
I use #365 to collect simple bugfixes to be released soon, and I have chosen to base such PRs on
masterto enable other PRs (not part of the upcoming bugfix release) being based ondevin parallel. The next PR to be merged intodevis #251, but I've been too busy lately to look into that yet.However, it's normally trivial to rebase a PR branch from
devtomasteror vice versa (unless the amount of change conflicts is huge) if priorities are changed. We are all free to argue for which PRs to include in a release, and if you feel e.g. PR #357 is important to release before a future v0.5, then please describe your reasons for that in a comment. 😃Normally, I recommend basing a new PR on
dev, but if it's a bugfix or other minor change with high priority, then you probably should argue for basing it onmaster.martinrieder commentedon Jun 8, 2024
@kvid wrote:
Dito. I get the impression, #251 would definitely demand an 0.5 release branch or even a major step to 1.0...
I would love to see semantic-release in action by then. There is a python-specific version called python-semantic-release...
That is the reason why Semantic Versioning states clear rules and leaves out the personal feelings. If we were to follow these, #357 is a feature that would be part of 0.5.
There is another argument for basing it on
masterin the GitHub Docs about tracking issues and PRs:Note that I do not intend to influence the way that you have been working on this project. I am just giving hints on what could be improved. As long as you can handle things manually and there is no disagreement amongst the collaborators, just keep going without semantic-release. It simplifies and automates some chores, but it also adds dependencies, complexity and thereby limits the freedom that an innovative project needs in early stages!
My actual intent was only to ask for a list of feature priorities for the next release, possibly discussed in a dedicated issue! If you think that this issue is the right place to discuss this, then I am also fine with it.
EDIT: I found this #320 (comment) by coincidence, asking for help on untangling #251 commits.
kvid commentedon Oct 4, 2024
@formatc1702, @amotl, @martinrieder - Please consider my suggested way to merge as described in #408 (comment) with hight priority, or suggest alternatives.
17o2 commentedon Jan 16, 2025
FYI, I have been invited by @sethhillbrand to give a talk about WireViz in the Open Hardware and CAD/CAM track of FOSDEM 2025 in two weeks, on Feb 2. 🙂
Even though I have not been able to contribute to the project for a while, it will be nice to share this tool and connect with other hardware nerds. If you happen to at the event as well, feel free to ping me (e-mail preferred)!
And again, thank you everyone for keeping the ball rolling... ❤
17o2 commentedon Feb 9, 2025
Quick heads up: I'm updating my user handle across various platforms*, and this includes GitHub. Sorry if this causes some confusion. This project/repo should not be affected. Some old @ mentions may no longer work, but nothing big should break.
* from @formatc1702 to @17o2
17o2 commentedon Mar 8, 2025
The refactored code has been merged into
devvia #447 , a compacted version of #251. The internal version has been bumped fromv0.5-devtov0.5-dev+refactor, based on PEP 440.Regarding semantic versioning, IMHO it becomes extremely important once you have a "stable" v1, and need to clearly distinguish between breaking and non-breaking changes. At v0.x, I consider the code to be in flux and reserve the right to fully break backwards compatibility for the sake of improving and maturing the codebase. See the note that has been in the Readme forever ;)
I look forward to reaching a point where we can talk about a true v1, but that's not today. Inkscape also took its sweet time and there's nothing wrong with that.
kvid commentedon Mar 14, 2025
@17o2 wrote:
Great news!
I've been on travel, and haven't been able to follow up much since I found the solution to #441, verified #443, and created #445 in February.
I agree...
Do you know if anyone recorded your talk at FOSDEM 2025? I would be glad to see it.
17o2 commentedon Mar 14, 2025
The talks were recorded, and I received a link to review the video. It had some gaps (technical issues, probably), so I reported it. I guess it should be released once it's fixed, or once it's clear that the missing bits are gone for good. They were not massive dealbreakers. It should then appear on the talk page itself.
amotl commentedon Apr 22, 2025
@kvid: Apologies for missing this. @17o2: Nice that you gave a talk at FOSDEM. I am looking forward to watch the video when I get back to better connectivity.
@amotl: Note to self: It looks like wireviz-web needs a few updates to accompany more recent releases of WireViz.FYI: We also just updated wireviz-web and released version 0.4.2, which uses the latest WireViz 0.4.1.Thank you everyone for your excellent work on WireViz.
kvid commentedon Jun 7, 2026
@17o2 and @amotl :
To avoid users loosing faith in our project, I suggest publishing a new release with small changes that are easy to merge into
devfor v0.5 later. See my preparations in PR #500.I was not able to find the video from FOSDEM - if anyone found it, please provide a link here.