In the change log I see an upcoming major release 13.0, with many breaking changes. How much trouble would it be to make an intermediate minor release with only recent bug fixes, and no breaking changes?
Could you share some more context? Are you particularly worried about any of the breaking changes; how will they impact you?
We have always done linear releases in the past and it would be a bit of work to change that.
@mark Thanks for your quick reply. Short answer: Never mind, I withdraw this request. It is not needed any more.
Details:
-
I was hoping for a bugfix minor release to harvest the fix for issue 2631 (completed). This was to fix MacPorts issue #71615. I wanted to compare the amount of work to create a Macports patch, versus the work to add this Graphviz minor release. Reading between the lines of your comment, it is far less work to patch MacPorts, rather than to interrupt the Graphviz normal release procedure at this time. Therefore the request is not justified.
-
Someone else beat me to that Macports patch before I could even think about it. So, minor release is not needed!
Oh, wow. Impressive how fast the macports folks can patch things!
It often does not work that way. This particular Graphviz flaw was on someoneās radar because it was a ācurrent issueā, causing trouble for dependants elsewhere.
I counted 206 dependents of Graphviz currently in Macports.
port list depends:graphviz | wc -l
Ryan Schmidt is coincidentally both the Macports Graphviz maintainer and a maintainer of Macports itself, thus quite proactive. It is not uncommon for him to patch a fix into the Macports Graphviz package prior to a fix landing in Graphviz itself. I expect him to backport e.g. smyrna: fix crash when trying to edit attributes with no open graph (!4187) Ā· Merge requests Ā· graphviz / graphviz Ā· GitLab too.