CONCEPT: UDF Updater allowing to update the UDFs between releases of the AutoIt3 installer

[WildByDesign]

32 minutes ago, jpm said:

I will upload it in an Autoit\Aplha dir similar to the Beta one

Like that I will be the @Jon deliverer  of the alpha update in sync with SVN

This is perfect. Thank you. I appreciate it.

On a side note, I appreciate everything that you have done for AutoIt over the years. Thank you.

[Jos]

@JPM, I would hold of on any process yet that requires your manual intervention, unless you have access to the svn hooks and can make it an automatic process.

Let's first see the goal and then try to come up with a process that works preferably automated.

[Jos]

1 hour ago, WildByDesign said:

I just wanted to point out a foolish mistake on my part pertaining to the thread title "...& Decoupling UDF Files from AutoIt Installer".

updated...

[MattyD]

@WildByDesign forgive me if I'm wrong,

I think this was originally around nabbing those updates to the udf library between AutoIt releases. The whole github part was secondary - around the delivery mechanism, and versioning between releases etc. So the simple alpha uploads should fit the bill adequately enough .

Having 2 diverging, competing copies of the same udf suite seems bonkers to me. Having a second community repo that extends the standard udfs (with no overlap) might have merit i guess,  but that's probably another conversation.

Edited yesterday at 01:40 PM by MattyD

[SOLVE-SMART]

13 minutes ago, MattyD said:

The whole github part was secondary

That is also my understanding, however I have now re-established and configured the following GitHub organization, which I have had for some time and used in the the german AutoIt community. These repositories (german related) are hidden (private) for now. So you will not be distracted by them 👌 .

💡 Spoiler, because not everyone is interested in the GitHub discussion (in this thread):

Spoiler

https://github.com/AutoIt-Community

Like @genius257 suggested:

• Create a new GitHub organization or use an existing if applicable. ✅
• Setup global repository ruleset(s). At least one ruleset should require pull requests to merge to - master/main, and at least one pull request review, to merge. ✅
• Invite relevant users and setup permissions. ✅
  • For now, I invited @genius257 and @WildBeDesign because I know their GitHub accounts.
  • Additional member or non-members but "Outside collaborators" can be added easyly later.
  • The "Members" of the organization are also restricted quite a lot for now, because I would add more permission from time to time.
  • The "Outside collaborators" would have only access to specific repositories, not the whole organization.
• Create a new repository for the organization, as a proof of concept. ✅
  • https://github.com/AutoIt-Community/playground
• Create the license file. ✅
  • I started with the playground repo with the default and very open source like MIT license.
• Decide on a versioning standard. I would suggest semver, but that is just my preference. ✅
  • I started with SemVer, yes.
• Decide on how to document dependency version requirements, preferable in a format for a script to use. 💡 (not done yet)
• Optionally have a maintained changelog file. my personal prefence is the Keep a Changelog standard. ✅
  • I started with the Keep a Changelog standard, yes
• Create a code of conduct. More information here, if needed. 💡 (not done yet)
• Create guidelines for contributors. 💡 (not done yet)
• Optionally there are issue and pr templates in GitHub, if relevant. 💡 (not done yet)
  • I added two example GitHub issues to demonstrate the handling.
• I would also suggest setting up GitHub workflows for automated tests, like linting, maybe testing functionality. This will also help in pull requests, before any reviewer needs to be involved. 💡 (not done yet)

==> Let me know who also wants to join that tryout GitHub Org. community 🤝.

==> Why I did (maybe) the seconds step before the first one? The "how" before "what"?

Because in any case, I will start by a tryout/playground for the community or for those who are interested in. In case the GitHub Orga. actions won't have anything to do with the intention of this thread at the end, it doesn't matter to me. I want to have a starting point and the need for other AutoIt-related actions will then arise on its own.

Best regards
Sven

[WildByDesign]

16 minutes ago, MattyD said:

I think this was originally around nabbing those updates to the udf library between AutoIt releases. The whole github part was secondary - around the delivery mechanism, and versioning between releases etc. So the simple alpha uploads should fit the bill adequately enough .

I agree 100%.

17 minutes ago, MattyD said:

Having 2 diverging, competing copies of the same udf suite seems bonkers to me. Having a second community repo that extends the standard udfs (with no overlap) might have merit i guess,  but that's probably another conversation.

I can only really speak for myself based on my initial thoughts. My intention of having some sort of "repo" initially was only for the sake of taking some heat off the AutoIt servers. I didn't want something that could add to that load. But I've since realized that any kind of additional traffic would be incredibly low because the amount of users desiring to keep their standard UDFs up-to-date would be low. Plus the size of the compressed UDF files is also quite small.

The "repo" aspect may very well not be necessary now. The UDF updater script could simply grab the alpha UDF archive (only it if has been updated), extract that archive locally and copy over the previous ones. A GitHub repo might be useful if the community wants to do the other aspect of community UDF files and updater for those. Although that would be a separate project and separate thread from this one.

I personally would like the standard UDF files to remain identical to the ones from the SVN server. I think that any changes should continue to be made only by those developers and MVPs who currently already do that. And if, for example, an outside user wanted to share some type of code change, it would absolutely need the review and blessing of the same fantastic individuals.

In short, nothing should change with the actual standard UDF files. They have that "official" blessing for a reason. If there is such a repo to hold (and maybe rename zip archive, restructure or whatnot for delivery), the actual standard UDF files there should match the UDF files from the SVN server 100%.

[WildByDesign]

8 minutes ago, SOLVE-SMART said:

Because in any case, I will start by a tryout/playground for the community or for those who are interested in. In case the GitHub Orga. actions won't have anything to do with the intention of this thread at the end, it doesn't matter to me. I want to have a starting point and the need for other AutoIt-related actions will then arise on its own.

This is fantastic. I can still imagine a lot of other purposes for this. Obviously, much of that will be topics for another thread. We can work on the updater script there for this standard UDF updater. The GH actions can potentially check for updates to the zip archive on the AutoIt server, fetch it if there are changes. If we need to rename the zip file according to SVN revision number, that can be done.

And then of course something similar could be done there with community UDFs and more. But again, that would be another topic of discussion.

[argumentum]

James bond (007) had license to kill, but I doubt there was a consortium like in GPL. WTFPL is a type of license, but a license is just a type of agreement and that's about that.
Pointing to AutoIt Software License should suffice, unless GH only have an assortment from a pull down menu.

Edit: didn't see that there was this 3rd page 🫣

Edited yesterday at 03:14 PM by argumentum

[argumentum]

4 hours ago, jpm said:

I understand you want an update of the UDFS part in Sync with SVN
So I will work on a autoitudfs-v3.3.19.0-alpha1.zip delivery

autoitudfs-v3.3.19.0-alpha<SVN revision number>.zip  would be better when you find a way to automate the building of the zip file.

[mLipok]

10 hours ago, Jos said:

@JPM, I would hold of on any process yet that requires your manual intervention, unless you have access to the svn hooks and can make it an automatic process.

Let's first see the goal and then try to come up with a process that works preferably automated.

Could this also include the current changelog?

It might not be important to me because I can see it directly in SVN, but I think people without direct access to SVN would be interested in this.

[WildByDesign]

30 minutes ago, mLipok said:

Could this also include the current changelog?

It might not be important to me because I can see it directly in SVN, but I think people without direct access to SVN would be interested in this.

This actually sounds like a great idea. That would also give indication of whenever any script breaking changes have been introduced. I would assume that is not very often, but that would be very important.

[argumentum]

Each entry in SVN has the revision number, action type, author and message.
In the message we enter details, that in my case has explanations and a link to the source material to read up on why was there a change or addition.

Having the logs, do help the reader know why something changed.

Edit: and yes, I see that JPM is working on the logs too 

Edited 20 hours ago by argumentum