I have been checking if there is way to have versioning display the JIRA numbers we work on. Currently versions help compare with previous version and inside interfaces we have to make comments with JIRA ticket numbers to understand why we did a specific piece of code. But if its possible to have the JIRA numbers displayed on each version wouldnt it be great to have only one final version of each change and delete all the previous ones like Save Final Version with JIRA number may be add comments to each version. Will it take up a lot of memory at Appian end? Currently we have only packages with JIRA ticket numbers and to find why we did some change for a specific line we need to add comments everywhere adding up the lines in Dev block. This way if we need to find for a particular ticket what changes we did would be easier. because sometimes making a start end block with JIRA numbers for small changes in same conditional block or same piece of code kills the code view.
Discussion posts and replies are publicly visible
I agree. Currently we also use a header block in code to reference ticket IDs. Not great, but the best we can do.
I also think that being able to add notes to design objects would help a lot in terms of traceability.
Exactly
Appian’s versioning is designed for audit and rollback, not for ticket labeling. Instead of embedding JIRA references throughout the code, the recommended approach is to use version comments and package naming for traceability. This keeps the code readable while preserving a clear link between changes and business requirements
Where do you put version comments?
You can use the Description attribute of the object and mention the JIRA number in description box for quick information. For each version description is versioned as well and are visible in the Versions dialog too for quick insight. Just devs should be trained to update the description when they start making changes as per a JIRA ticket.
Update the description field each time you save the object (add JIRA number there). Also, you can filter objects by description to quickly add them to a package. Deleting old versions saves negligible memory; keep them for audit trail and only remove unnecessary intermediate saves.
I'm not sure whether Vinod uses some more formalized system, but I've taken to (very intermittently and only where relevant) leaving regular in-code annotations documenting the (dev) version number wherein some major change originated. These I'll either just leave in place indefinitely or, eventually as desired, remove when no longer relevant. Similar in a way to process model annotations that note a version number (and where I name a version I'll usually specify "dev version" so nobody gets confused if they see the comment in the Prod object and see it doesn't even come close to lining up).
Thats a good option. Thank you!