v1.2 — Known issues and temporary Full Update recommendation

[TMailletFR]

Known issues identified after the v1.2 release

Following additional real-world testing, several regressions have been identified in ProjectEngine v1.2.

The most important known issue concerns the incremental Update Gantt workflow. Some changes to predecessor relationships—particularly removing a predecessor or changing its relationship type—may not be fully detected. This can leave scheduling logic or displayed dependency links temporarily out of date.

Until the corrective release is available, users are advised to run Full Update after:

adding, removing or modifying predecessor relationships;
changing relationship types or lag values;
resizing the columns located to the left of the Gantt timeline;
observing a dependency link that appears inconsistent with the current schedule.

Additional investigations are in progress regarding:

SS and FF relationships using summary tasks as predecessors;
SVG dependency alignment and arrow visibility;
Longest Path REX results in schedules without Actual or Forecast dates.

A dedicated v1.2.5 stabilization release is being prepared to address these issues. Its scope is limited to corrective work and regression testing; no new performance or architectural development will be introduced.

The current v1.2 release remains available, but Full Update should be preferred over incremental Update whenever schedule logic has been modified.

Thank you to the users currently testing the release. Further details will be published with v1.2.5 once the corrections have been validated.

[prabhjeet16]

Thanks for the transparency around the v1.2 issues and the temporary Full Update recommendation.

One thing that stood out is how difficult dependency-related regressions can be to track once scheduling logic becomes more complex. Issues like predecessor updates not propagating correctly, relationship-type changes affecting downstream behavior, or dependency links becoming inconsistent are often symptoms of how interconnected the underlying logic has become.

We've seen similar challenges in other projects where understanding the impact of a change is harder than making the change itself. That's actually one of the problems we're exploring at JigsawML. We help teams visualize code relationships, dependencies, and architecture flows so it's easier to see what may be affected when workflow or scheduling logic changes.

Looking at the v1.2.5 stabilization effort, I'd be interested to see how the update workflow and dependency graph are evolving. If you're open to it, I'd be happy to run the repository through JigsawML and share a free architecture visualization demo. I'd genuinely value your feedback on whether the insights would be useful for diagnosing and preventing issues like these.

[TMailletFR]

Thanks for the offer. The repository is public, so you are welcome to run it through JigsawML and share the resulting architecture visualization.

I would be interested to see how well it handles a fairly large Excel/VBA codebase, particularly relationships between standard modules, class modules, UserForms, worksheet events and the scheduling workflow.

There are also dependencies that are not always expressed through straightforward function calls, so it would be useful to see which relationships JigsawML can detect and where its limits are.

Please feel free to share the demo here or send me a link when it is ready. I’d be happy to give you honest feedback on whether it helps with understanding regression impact in this kind of project.

[prabhjeet16]

Thanks, TMailletFR

I’ve prepared a short walkthrough focusing on the areas you specifically mentioned: standard modules, class modules, UserForms, worksheet events, and the scheduling/dependency workflow.

🎥 Please find the video Link Here: https://drive.google.com/file/d/10odZZhsw1IdPzbv6tCsIeqd0uaEnC8j6/view?usp=sharing

The main goal was to evaluate how useful an architectural view can be when the relationships in an Excel/VBA application extend beyond straightforward function calls.

In the walkthrough, I’ve highlighted the relationships JigsawML was able to surface across the different VBA components, as well as areas where the dependency picture is less explicit or where additional context is needed.

I’ve also looked at the architecture from the perspective of the regression concerns you raised around the Update Gantt workflow and predecessor/dependency logic.

I’d genuinely appreciate your feedback on two things in particular:

• Does this view make the ProjectEngine architecture easier to understand?
• Could this kind of dependency/architecture view be useful when investigating the potential impact of changes to the scheduling workflow?

Thanks again for giving us the opportunity to test JigsawML against a real-world Excel/VBA codebase. Your honest feedback — including where the analysis falls short would be very valuable to us.

For anyone interested in exploring the architecture analysis further:

https://www.jigsawml.com/

[TMailletFR]

Thanks for preparing the walkthrough. The visualization is clear, and I can see how it may help someone unfamiliar with the codebase understand the main architectural areas and their relationships.

The analysis categories around bugs, testing gaps, performance and coupling also look potentially interesting.

One point I could not determine from the video is which exact repository state was analyzed. ProjectEngine has several public releases and the code has changed significantly between v1.2, v1.2.5 and the current main branch.

Could you confirm the branch and commit SHA used for the scan?

That distinction is important here, because some of the dependency and incremental-update issues described in the original discussion were already corrected in later revisions. It would also help me assess whether the reported findings refer to the current codebase or to an older release.

For my own workflow, I already use tools that have access to both the current code and its history, so the architectural overview is less essential for me personally. However, I can see value for onboarding or for giving an external reviewer a faster high-level understanding of a large VBA project.

I would be particularly interested in any concrete finding that JigsawML believes is still actionable on the exact commit analyzed, especially if it can point to the relevant modules or call paths.

[prabhjeet16]

Thanks, TMailletFR — that’s a fair point. The exact repository state is important here.

I’ll confirm the branch and commit SHA used for the JigsawML scan, then share a concrete finding from that same code state, including the relevant modules/call paths and any limitations in the analysis.

That should be a better way to evaluate whether JigsawML adds value beyond the tools you already use.