CFU should not double projects in "Updates" and "My Updates"

[lscheffler]

When a project that is published is doubled up to My Updates folder (for example, for development) it is listed twice in the CFU form.
It is intended that the project in My Updates shares the App_Id with the project in Updates.
The problem is, version number might change, and CFU starts to highlight to "official" entry because of new version found. I know, this is ordered in some kind, but this is not fool proof.

What I like to have changed:
If a file in Updates shares App_Id with a file in My Updates, ignore the file in Updates.

If somebody likes a beta like version in parallel to the "official" one, a different App_Id must be created, but there might be a lot more work to do. This is for testing on a developers computer.

---

If you'd like to see this feature implemented, add a 👍 reaction to this post.

[Jimrnelson]

This seems like an incomplete understanding of what "My Updates" is for and how it works. Small wonder, it's been scarcely used over a dozen years and I am not sure what documentation exists.

What's being asked for here can be achieved another way, using the "Never Update" column in CFU.

If you are interested in temporarily disabling normal updates to your project and only have the "My Updates" version show up, just mark "Never Update" for the normal one. You can remove the "Never Update" flag later, when your testing is done and you remove the file form "My Updates".

Now, as to how "My Updates" works --

The intent of "My Updates" is to provide a local sandbox for the development of either new projects or significant upgrades to existing projects.

When creating a new project, "My Updates" is used for initial development of the Thor updater and related URLs and version files. Depending on the size and scope of the project, the new updater might be later shared with a select group of other developers for testing and commentary before releasing to the entire Thor community. While new projects are rare these days, this is a necessary step in their development.

For existing projects, "My Updates" is used for the parallel development of major version changes. For instance, if (hypothetically now), someone was to work on an upgrade of PEMEditor from version 7 to a new version 8. The developer would want to have the old version (7) available for use while still being able to work on and enhance the new version (8). This is done by treating the new version like it is a completely new project: the updater in "My Updates" would new to reference:

• a completely different version file URL
• a completely different zip file URL
• a completely different home folder
• and (if an App), completely different Thor tool names.

This is what was used in the transition from GoFish 4 to GoFish 5, a process that took quite a few months.

[lscheffler]

I give the Never update a try. If it does not highlight, if a new different version is available, it will do.

The major thing is
All in "My Updates" is identical, except the URL (for github, just a different branch will do) There is simply no need to have all the other stuff set. Without any doubt, this will run on a different Thor installation There is no need to fiddle with directories etc. Only that the, in this case useless, file item "Updates" hangs around.

I understand that some fiddle testing into working Thor, but then my dev system is not customers system as well. So I use a distinct install of Thor for testing.

[Jimrnelson]

Your updater must have different URLs for both the zip file and version number file (that is, different than the public version of your project.)

If not, than making changes in your branch is just releasing those changes to the Thor community.

I have no doubt that your work on branching serves you well in your local environment, but to keep your local changes distinct from those released to everybody, you'll need distinct URLs. In effect, it will look like a new project.

When you do it this way, making changes to your branch will show up at the top of CFU, ready to update, and the public version, which is already current, will be further down on the list, and should cause no confusion for you.

Also .... and this should be a separate topic ... I do not understand why, if you are only running this locally (not with other developers), why is CFU even involved?

[lscheffler]

Jim, a different branch on github will result in a different URL.
For example

lcRepositoryURL  = 'https://github.com/lscheffler/sf_regexp'
	&& the URL for the project's repository
lcDownloadsURL   = strtran(m.lcRepositoryURL, 'github.com', ;
	'raw.githubusercontent.com') + '/main/ThorUpdater/'
lcVersionFileURL = m.lcDownloadsURL + 'SFRegExpVersion.txt'-	&& the URL for the file containing code to get the available version number
lcZIPFileURL     = m.lcDownloadsURL + 'SFRegExp.zip'
	&& the URL for the zip file containing the project 

the main in lcDownloadsURL is the branch. Using branch "Cow", this changes to Cow. As simple as possible.

And this is the whole change to the file in My Updates.

I know that it is sorted different. I marked version anyway, or it was done automatic, can't remember, at least it was odd.

There is no other change, no directory no nothing, just the development identical to my master branch. Just it is not public.

Why I do change what where is something more philosophical then branching. We go into this over a beer next September. But please, not online. At least you will understand that I do not develop inside Thor's structure, but my program should run there, using parts of Thor. So it must move into Thor, and what could be faster then a git push and invoking CFU to do this? With VFPX Deployment it's just some simple keys to do.

[lscheffler]

A perfect example what I count strange:

It comes even worst, if the version on "Updates" and "My Updates" URL differ.

[Jimrnelson]

Implemented in Thor 1.47 - Released 2024-01-04 (#244)

In the CFU screen, hide 'Normal' updates if there is a "My Updates" file with the same AppID property (which must not be empty).

This property, available but rarely used, would need to be set in the version files for both updaters.