Idea improvements to pre-release and upgrade to provide more information

Developers
#1

Folks I would like your view or implementation of this;

Idea improvements to pre-release and upgrade to provide more information, on changed tiddlers.

Could we have both the prerelease and post upgrade, provide a list of tiddlers that were changed in anyway as a result of that upgrade,? even it is only within that specific release version?

  • Even better if it were all tiddlers change eg upgrade from 5.3.0 to 5.3.3 those changed in any of these versions. List title only once if changed in more than one version would be suficent.

See where this idea came from Edit window very small - #6 by TW_Tones

This would allow two things currently not easy to do, Allow the list of change tiddler to be used;

  • In the prerelease site to find a fix that is included and using it as a work around on an existing wiki through drag and drop.
    • This would allow a temporary fix to be applied before the next release reducing pressure on the development team to publish the next release.
  • Once a wiki has being upgraded having access to a list of the changed tiddlers would allow a targeted review of such tiddlers that whilst changed in the core may not have changed due to an overridden shadow.
    • This would make finding earlier patches as above and other core overrides that may be of consequence.
    • This tiddler list could be deleted (if not a shadow tiddler) or is bundled in a plugin if no nonget needed, but since it is only a list of titles it should be somewhat compact.

I raise this here in the developers forum because I believe the only way to implement this may be within the GitHub process.

  • I would also contend in the scheme of things not that many tiddlers or bytes change with any give upgrade.
#2

@pmario thanks for contributing by editing my post, but I can’t see what you actually edited, is there a way?, or could you leave a note when you do please?

#3

Top right of the post is a orange “edit” pencil icon. If you click it, you can see the diff. It was a typo in the thread title.

#4

Thats what I thought, I could not see any highlight but now I do, the problem is my dark view the highlight is not obvious.

  • Thanks for that :+1:
1 Like
#5

I know it’s not precisely what you’re looking for, but it might be a start at that: Git’s diff feature, which GitHub exposes for tags, commits, etc., can give you the list of files that changed between two different versions; and it shows you how they’ve changed.

For instance, in the last big change, between 5.3.1 and 5.3.2, we can see this:

Where 365 files were changed, almost all of them tiddlers.

Or in the recent bug fix release,

only 27 files were changed. You can do this for any two versions tracked in GitHub.

But, while listing changed files might be helpful, having lists with hundreds of changed files might be overwhelming. If you compare 5.2.7 with 5.3.3, it’s 898 files.

So I think the interface to present this might become awkward.

#6

Thanks for looking at this @Scott_Sauyet you have demonstrated the list is available in github. The value would be if the list of changed tiddlers was contained in a summary tiddler after using the upgrade tool. Idealy as a plain tiddler or its own plugin so is easily deleted.

1000 tiddler titles seem like a lot, but its unlikely to be an issue. Keeping in mind the upgrade actualy changes this many tiddlers, all we need is the title list.

I have not proposed an interface to present this, only that the list be available and deleteable.

However if I were to write one with the current plan we only need to list a subset of tiddlers which have shadows, that have being overwritten and perhaps tools to review the differences.

  • keep in mind i am not looking here at the differences between versions beyond the titles, because its main purpose is to expose the differences between core tiddler s and overwritten tiddlers in a specific wiki.

In responding to your reply other ideas have come to mind. If nothing else, if there were lists of the titles changed, publicaly available for each version. Perhaps even a data tiddler or plugin, perhaps in a library. This process can proceed in a manual way. This may be a good start to explore the idea.

  • if available for the current prerelease it may also help people explore the changes, even extract workarounds until the next release.
  • if a seperate set of changes where available each release, we could even package the actual changed tiddlers not as shadows, in a json, so the changes can be reviewed in a tiddlywiki without resort to github.

One other approach maybe to add a system field in all tiddlers that change indicating the version in which it last changed. Using a single character would be sufficent.

  • this would allow one to review the changes without a seperate list.