Some plugins always install in latest version

[pluspol]

Hi there,
I've experienced that some plugins always install in the latest version although an older version is specified in composer.lock

        {
            "name": "wpackagist-plugin/cf7-grid-layout",
            "version": "4.13.0",
            "source": {
                "type": "svn",
                "url": "https://plugins.svn.wordpress.org/cf7-grid-layout/",
                "reference": "trunk"
            },
            "dist": {
                "type": "zip",
                "url": "https://downloads.wordpress.org/plugin/cf7-grid-layout.zip?timestamp=1653228166"
            },
            "require": {
                "composer/installers": "^1.0 || ^2.0"
            },
            "type": "wordpress-plugin",
            "homepage": "https://wordpress.org/plugins/cf7-grid-layout/"
        },

This seems to be related to download URLs that don't include a version number but a timestamp. Because these links seem always to point to the latest version the wrong version might be installed.

I've opened an issue in the plugin support forum and the author needs some hint where to change the download url:
https://wordpress.org/support/topic/include-version-in-download-url/#post-16078572

He also points out that older versions are available through this page:
https://wordpress.org/plugins/cf7-grid-layout/advanced/#download-previous-link

So maybe it's possible to always use these "previous download links" and not the default link on the blue "Download" button.

Currently we've seen this with the following plugins:

• https://wordpress.org/plugins/captcha-solution/
• https://wordpress.org/plugins/cf7-grid-layout/
• https://wordpress.org/plugins/cf7-polylang/

Best regards

[aurovrata]

Looking at this, I initially thought it could be linked to the readme file's Stable tag attribute, which is often set to trunk on some plugins (eg. The Smart Grid extension on which this issue was initially raised). However, changing this attribute's value to the latest version does not affect the download link.

[aurovrata]

@pluspol could you try chaging your composer json file to

"name": "wpackagist-plugin/cf7-grid-layout",
            "version": "4.13.0",
            "source": {
                "type": "svn",
                "url": "https://plugins.svn.wordpress.org/cf7-grid-layout/",
                "reference": "tags"
            },

ie reference the tags rather than the trunk. The trunk always has the latest code, the tags have the latest as well as older version.

[pluspol]

I've found the following file:
https://github.com/outlandishideas/wpackagist/blob/develop/src/Entity/Plugin.php

There it states that if only the trunk gets updated wpackagist will create those timestamp urls.
So could you please check again in the SVN @aurovrata ?

Using the package from SVN is also a solution but not our preferred one.

[pluspol]

I think I found it:
https://github.com/outlandishideas/wpackagist/blob/develop/src/Service/Update.php#L115

If the current version (in this case 4.14.1) doesn't exist as tag (and it doesn't) the trunk will be used for this:
https://plugins.trac.wordpress.org/browser/cf7-grid-layout/#tags/

So I think you need to add the latest version as tag @aurovrata .

It's the same with the other plugin I'm having problems with:
https://plugins.trac.wordpress.org/browser/cf7-polylang/tags
There 2.4 is the latest tag but the latest release is 2.4.1

So the specific issue isn't a bug in WPackagist but one could argue that the current behaviour is kind of a footgun because you're expecting to install an exact version and only realize later that you're not.

So I would suggest that installing a trunk version shouldn't be the case here. In my opinion it would be more correct to simply not provide the version if it isn't tagged correctly. Or provide it only as an explicit dev version.

[aurovrata]

It is a common practice across the WP repo to only tag major release versions, and minor release (that fix bugs) should in any case be updated to the latest version in that major release. I have adopted that practice as it also reduces the amount of storage used by the tags svn folder.

Therefore I would suggest you configure your package to use 4.X versions and not bother with sub release such 4.X.x. The sub-release always fix bugs. New features always bump the major version number.

Let me know if this works.

[pluspol]

I think there are some separate aspects to discuss and most of them are not related to WPackagist.

Related to WPackagist:

• As described above I'm not sure whether the current behaviour of downloading untagged versions from trunk is expected and safe. Because of this until someone updates the dependency in the project and this update might switch to a specific zip file instead of the trunk zip file, the latest version might get installed instead. (E. g. developer A installs the project on Monday and gets version 1.7.0, developer B installs the project on Friday and gets version 2.0.0 besides 1.7.0 being saved to the lockfile) - So it could also lead to a new major version getting installed silently (if the package follows SemVer)
• In my understanding installing from a lockfile (in a similar environment) must always result in the identical setup regardless of the date.

Unrelated to WPackagist:

• WordPress encourages to use SemVer for versioning but it isn't enforced. And in my experience we can't rely on it. Instead many plugins use other means of versioning. Also WP Core isn't versioned according SemVer.
• Because of this always updating to the latest version might lead to unexpected changes. Also every bugfix release might introduce new bugs depending on the QA process quality.
• Honestly I don't know how SVN does it but Git would reuse files stored in multiple folders/tags therefore storage wouldn't be an issue there. Also I think storage isn't a good argument here as it only affects the SVN and not production code. In my opinion sacrificing stability for storage efficiency isn't a good trade-off.
• Using 4.x as version (actually we even use * for plugins because of the lack of SemVer consistency) doesn't change the problem as because of this bug the trunk version might get installed. So it is possible that even a 5.x version gets installed when it reaches the trunk and the lockfile still has the reference for the trunk zip file.

WP also recommends tagging every release:
https://developer.wordpress.org/plugins/wordpress-org/how-to-use-subversion/#tags

It is important that you always use tag folders and proper versioning to ensure your users get the correct code.

https://developer.wordpress.org/plugins/wordpress-org/how-to-use-subversion/#trunk

The /trunk directory is where your plugin code should live. The trunk can be considered to be the latest and greatest code, however this is not necessarily the latest stable code. Trunk is for the development version. Hopefully, the code in trunk should always be working code, but it may be buggy from time to time because it’s not necessarily the “stable” version. For simple plugins, the trunk may be the only version of the code that exists, and that’s fine as well.

I hope I'm not being unpolite or too harsh. I just want to make clear my point of view. And if the system doesn't work as expected it could lead to major reliability and trust issues.

[khromov]

It is a common practice across the WP repo to only tag major release versions, and minor release (that fix bugs) should in any case be updated to the latest version in that major release.

In my experience this is not very common and definitely not recommended, the Plugin guidelines recommend one tag folder per version.

Releases in the tags/ should of course also be immutable, otherwise you don't know what you're installing.

@pluspol As you mentioned, the problems arises from incompatibilities between how Composer works (broadly: very strict) and how the WPorg repository works (broadly: pretty relaxed, eg you can have only trunk with no tags, modify or remove older tags, etc).

I do think the behavior that a plugin version without a tags folder return trunk as the download link fails in the users expectation of what they are going to download and should be changed. Because this is just incorrect behavior, eg some authors delete tags for older versions of their plugins and pointing these to trunk has very unintended consequences. If a plugin only supports trunk then the user should select the trunk version via their composer.json.

[aurovrata]

It is a common practice across the WP repo to only tag major release versions, and minor release (that fix bugs) should in any case be updated to the latest version in that major release. I have adopted that practice as it also reduces the amount of storage used by the tags svn folder.

I need to correct myself, I mean patch versions are not commonly tagged, major and minor versions are, which I follow in my plugin development. Wp Guidelines does not specifically recommend to tag patch versions as per the semantic version convention.

[aurovrata]

As described above I'm not sure whether the current behaviour of downloading untagged versions from trunk is expected and safe.
@pluspol that's not what I am suggesting. Major.minor versions are all tagged and these are the ones you should be using if you want to download an older version, which will have the latest patch.

Trunk is for the development version.

this is true if one uses SVN for development, but I don't know of any plugin that does. As for my I develop on GitHub only, and deploy on WP SVN.

The trunk can be considered to be the latest and greatest code,

which is true in this case.

I do think the behavior that a plugin version without a tags folder return trunk as the download link fails in the users expectation of what they are going to download and should be changed. Because this is just incorrect behavior, eg some authors delete tags for older versions of their plugins and pointing these to trunk has very unintended consequences. If a plugin only supports trunk then the user should select the trunk version via their composer.json.

@khromov I agree, but isn;t the case here. The problem arose from trying to get patch versions which do not exists in the tags folder. So v4.12.10 for example does not exists, and as such defaults to trunk, but version v4.12 does exists and contains the latest patch in that minor update, v4.12.13 which is the correct version to use in that minor version 4.12

[pluspol]

Sorry, I misunderstood your tag handling. When I understand it correctly you update the minor tag version with the latest patch release.

This reminds me of Docker hub where besides exact versions like 1.2.3 there often are upgradable versions like 1.2, 1 or even latest. However in Docker universe that makes sense because:

• Currently there are no versioning ranges.
• Tags are not thought to be immutable
• Besides these upgradable tags there mostly are specific tags that mostly only change when underlying images had some security issues

But in Composer (and other package systems) things are different as pointed out by @khromov:

• Versioning ranges explicitly state which versions to accept and avoid
• Packages are meant to be immutable, so applying patches to a minor version release would lead to issues as they wouldn't get picked up by Composer installations automatically. Instead there's another race condition happening: Dev A installs the project in version 1.2 on Monday and gets a version which has some nasty issue. Dev B installs the project in version 1.2 on Friday and gets a version where this issue already has been fixed because 1.2 has silently being updated to 1.2.1 and the linked zip file has changed. This realization bothers me TBH.

So this behaviour once again would break one of the central contracts of package systems like composer: Packages must be immutable.

The trunk can be considered to be the latest and greatest code, however this is not necessarily the latest stable code.
This statement contradicts itself because trunk might be unstable and therefore can't be the greatest code. :)

Wp Guidelines does not specifically recommend to tag patch versions as per the semantic version convention.
The guidelines state that you should always use tag folders for your versions and patch versions are also versions. So because of this I see ne reason why patch versions should be treated differently.

In general this also shows that the whole WP plugin ecosystem and composer integration is a bit of a gamble because plugins are versioned as they wish and composer has strong requirements regarding versioning. Immutability for versions heavily relies on plugin authors as long as WPackagist uses the download urls provided by WP.

IMHO because of this a stable and reliable handling can only be achieved by mirroring these zip files (and make them immutable) and maybe creating own versions for changed zip files. I don't know whether this is realistic or necessary as this problem doesn't seem to be as obvious, known and critical until now.

[aurovrata]

applying patches to a minor version release would lead to issues as they wouldn't get picked up by Composer installations automatically. Instead there's another race condition happening: Dev A installs the project in version 1.2 on Monday and gets a version which has some nasty issue. Dev B installs the project in version 1.2 on Friday and gets a version where this issue already has been fixed because 1.2 has silently being updated to 1.2.1 and the linked zip file has changed. This realization bothers me TBH.

that's a good point, however, in reality this would not happen as tagged versions do not evolve beyond the latest version.

If the latest version is v4.2.1 and someone installs v4.1 (which is actually 4.1.4), this will not change going forward, only v4.2 will change but in line with the trunk.

If someone install the latest version (trunk), then surely they should be able to get an update trigger the same way WordPress plugin page does?

In summary,

• older tagged version X.x will never change, so you should be able to package them for release
• latest version from trunk will change, is there no way the packager can pick up the update the way WP does?

[aurovrata]

Looking over your thread in the plugin support, I realise that if you request a version which does not exists in the tags folder then it simply return the trunk version.

So if you request X.x versions older than the current one, you will get the versions available in the tags folder, and this will always give you the latest patch in that minor version.

For the latest code in trunk, I could delay the push into the tags folder until the minor version number updates, so say the last tags version is 4.2 and the current trunk is 4.3.2, but until the trunk updates to 4.4 or even 5.0 say, then v4.3 would not appear in the tags folder.

Would this work for you?

[aurovrata]

I just feel that patched versions will also confuse users who want to download older versions from the WP repo, and I feel its easier for them to always download the latest patch in that minor version by simply omitting the patch versions from the tags

[gruniversal]

I followed this interesting thread and in my opinion there should be a tag for every release and no tags should be altered afterwards. That includes bugfix release tags. I guess that is what most people would expect from semantic versioning since 4.2 is not the same as 4.2.x.

[pluspol]

applying patches to a minor version release would lead to issues as they wouldn't get picked up by Composer installations automatically. Instead there's another race condition happening: Dev A installs the project in version 1.2 on Monday and gets a version which has some nasty issue. Dev B installs the project in version 1.2 on Friday and gets a version where this issue already has been fixed because 1.2 has silently being updated to 1.2.1 and the linked zip file has changed. This realization bothers me TBH.

that's a good point, however, in reality this would not happen as tagged versions do not evolve beyond the latest version.

If the latest version is v4.2.1 and someone installs v4.1 (which is actually 4.1.4), this will not change going forward, only v4.2 will change but in line with the trunk.

I think it does matter in reality. It can happen everytime the lockfiles points to a minor release (without patch level) and was originally meant to provide an older version. This might happen with installations that don't get updated very often.
I think the damage would be fairly small in most cases where this happens, but in terms of the overall concept this still is a violation.

If someone install the latest version (trunk), then surely they should be able to get an update trigger the same way WordPress plugin page does?

I'm not sure whether I understand you correctly:

• As stated above (and confirmed by @khromov) trying to install an untagged version shouldn't automatically install the trunk version. This behaviour isn't related to specific plugins but to the WP plugin ecosystem and the way WPackagist uses it.
• If someone explictly installs the trunk version then only updating it via composer should update it to the latest trunk (composer update wpackagist-plugin/some-plugin). This might be done by using VCS as source and not the (ever changing) zip file because using the zip file once again would lead to silent updates.

• older tagged version X.x will never change, so you should be able to package them for release

• Do you have some sources that this is the recommended and established behaviour? I don't know if someone can realiably count on this.

• latest version from trunk will change, is there no way the packager can pick up the update the way WP does?

• Yes, the way would be e. g. using VCS as source.

For the latest code in trunk, I could delay the push into the tags folder until the minor version number updates, so say the last tags version is 4.2 and the current trunk is 4.3.2, but until the trunk updates to 4.4 or even 5.0 say, then v4.3 would not appear in the tags folder.

• On the one hand it's about your plugin but on the other hand it's about the general handling for plugins as not all plugins are versioned equally (sic! ;)) - So once again thanks again for discussing this heartily.
• This would not help as WPackagist (currently) would pick up 4.3.2 as trunk version and therefore would enter this dangerous path.
• IMHO the easy and safe way would be to tag every release and avoid updating already used tags.

I just feel that patched versions will also confuse users who want to download older versions from the WP repo, and I feel its easier for them to always download the latest patch in that minor version by simply omitting the patch versions from the tags

I don't have any statistics from the company but I personally would (when not using WPackagist) always download the file provided by the plugin home page. Normally I wouldn't use the advanced downloads because a) SemVer use can't be expected an b) only a few plugins might support older versioning branches. So when tagging all releases the download wouldn't point to the generic file some-plugin.zip but to the tag like some-plugin-1.2.3.zip. And I would expect the download to be a stable release and not some an unfinished dev version.

[pluspol]

Some additions regarding "is it allowed to overwrite tags".
SemVer which is the basis for Composer and recommended by WP states:
https://semver.org/#spec-item-3

Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.

Browsing through other issues it's apparant that these problems come up regularly and that versioning is handled diversely by plugin authors:

• No checksum for packages leads to problems #440: Version 1.9.3 changed. The proposal to include checksums in the package definitions to make these problems visible is great! But it might disrupt workflows and requires more knowledge from developers.
• Trunk is installed rather than tag for advanced-post-manager #292: Trunk version is installed

Non SemVer-compatible versions include:

• content-protector current version is 3.5.5.5.2 on wordpress but 3.5.5.2 on wpackagist #473
• Outdated tags for iwp-client #399

So besides avoiding unintended trunk installs I'm absolutely on board with checksums. Otherwise I think it all comes down to talking to plugin authors to stick more closely to SemVer.

I don't know if its possible to get someone from the WP team on board and discuss what might change in the documentation to make these things more clear and predictable.

Otherwise I think I'll scan our projects for instances where trunk versions have been installed.

[pluspol]

I've checked our projects for trunk installs of plugins and are quite surprised as how many different plugins (~18) this currently affects. I haven't checked them one by one whether the requested versions are tagged by now or if they just use the trunk for development.

[aurovrata]

So if you request X.x versions older than the current one, you will get the versions available in the tags folder, and this will always give you the latest patch in that minor version.

For the latest code in trunk, I could delay the push into the tags folder until the minor version number updates, so say the last tags version is 4.2 and the current trunk is 4.3.2, but until the trunk updates to 4.4 or even 5.0 say, then v4.3 would not appear in the tags folder.

Would this work for you?

@pluspol sorry for the delayed response, we were off for Diwali :)

Is the above proposal of using major.minor (vX.x) workable for you as all them have corresponding tags folder entries.

Wrt WordPress input, here is a blog post by Ipstenu from the plugins team on the topic, and my comment on the practice I follow.

[pluspol]

You're welcome. :)

Thanks for the link to the blog post. IMHO it highlights a few points:

• You also do this for a different usecase that is beta testing plugins. Let me get to that in a bit.
• Ipstenu underscores that every release should have a tag.

She doesn't write about immutability of tags (which also is a big must have for SemVer). Maybe we can get her thoughts on this? @Ipstenu

Otherwise I think we're going in circles until we agree on something and get some more participants.

• Mutable tags prevent use of signed releases and may lead to unwanted and untested changes.
• Trunk versions installed through WPackagist decouple versioning completely and will result in always getting the latest dev build until updating to a tagged release.

So what is realistically achievable?

• WPackagist could stop delivering trunk versions and do this only when explicitly requiring dev builds. This will lead to some plugins or updates not being available anymore.
• WPackagist could deliver hashes for verifications. However this quickly would lead to breaking setups.
• We can try to get some official input from WP.

Regarding your suggestion

In status quo this wouldn't help as it

• violates SemVer immutability
• still might result in trunk installs as long as readme.txt doesn't point to n existing tag

Avoiding trunk installs currently is only possible by finding a version that exists in the tags folder. So e. g. for your plugin cf7-grid-layout one must explicitly install 4.14 instead of * or 4.14.1.

Regarding beta testing

I totally understand and agree that it's important to have some kind of beta testing functionality. I think WP must provide a safe and official way for this.

I'm against offering trunk/dev builds for new users because:

• it might not be what one expects
• beta testing should always be done with explicit consent

Unfortunately I'm not very experienced with WP plugin development so I don't have any suggestions for a feasible alternative. But some options might be:

• Offer a beta download next to the stable download
• Provide some optin functionality in the WP backend to download beta releases for some or alle plugins/themes
• Offer the beta version as separate plugin (this should already be possible)

[Ipstenu]

As much as I would love to help it's just not enforceable from a practical level. Also the plugins team actually isn't in charge of that code, it would be the meta team.

From an enforcement, there's just NO WAY to force 100k plugins to wake up and smell the SemVer as much as I try :( We try to educate all the time, to point out we want to ditch trunk, but people are super slow to change.

I did make a related ticket in trac - https://meta.trac.wordpress.org/ticket/6380 - but right now the field is free-form and unless someone can write code to force that change, it's not going to be possible :/

My recommendation? I like this:

So I would suggest that installing a trunk version shouldn't be the case here. In my opinion it would be more correct to simply not provide the version if it isn't tagged correctly. Or provide it only as an explicit dev version.

If the version is trunk, or it's not found, congrats, you're non-compliant with this service, have a nice day.

As for Beta... That again would be a meta thing. They'd have to write out code to allow for a beta 'track' of some sort.

[pluspol]

Thanks for chipping in @Ipstenu 👍

If I understand your ticket correctly you also advise against overwriting tags. Is this correct?

Bonus, make sure we only check for the FIRST iteration (some people re-used Stable Tag per version in their changelogs).

This would also be in line with SemVer.

I've also written an email to the plugins team and got roughly the same response:

We currently recommend everyone use SemVer, however we don't have a way to enforce it. Yet.
We're actively working on disabling the trunk feature, so it won't load like that anymore, but it'll be a while since we don't have a lot of people who want to do Meta WP work :(

IMHO this means that official WP standpoint is:

• SemVer is recommended
• Trunk shouldn't be used for releases (and is planned to be disabled in the future)
• Reusing tags is also not recommended (any as a bonus goal also planned to be disabled in the future)

The limitations are:

• SemVer in its entirety is currently not enforcable because its not possible to check which changes are breaking (without exhaustive test catalogues)
• Dropping trunk and forbidding tag reuses is enforcable but might take a while because of lacking resources in the WP Meta team

So the most helpful thing to do might be trying to support WP Meta in implementing these changes which would bring the whole ecosystem forward and therefore also make WPackagist more reliable.

I for myself have to think about whether this is possible for me.

[Ipstenu]

Reusing tags flat out won't work. No one gets updated, nothing gets pushed properly, everyone loses.

Dropping trunk as stable is doable, but people will always reuse tags and wonder why it broke :(

[aurovrata]

In status quo this wouldn't help as it

violates SemVer immutability

I think you have not read what I propose properly, since this is not what I am suggesting.

Otherwise I think we're going in circles

agreed, and my bone of contention is that tagging every single patch version is too much disk space on my local machine. Unfortunately, I haven't found a way (like GitHub) to retain tags only on the origin.

Can you use the GitHub repo to pull patch versions?

[aurovrata]

Another solution would be tags all versions and delete older versions as the WP handbook suggests.

[pluspol]

Another solution would be tags all versions and delete older versions as the WP handbook suggests.

I don't know the internals of WPackagist but if this would mean that these deleted versions wouldn't be installable anymore, than this might also cause problems and would break with immutability.

my bone of contention is that tagging every single patch version is too much disk space on my local machine

How much space does this take up on your machine? These things shouldn't have an effect on end users, as "disk space" is considered cheap.
I've tried twice to checkout the whole repository under https://plugins.svn.wordpress.org/cf7-grid-layout/tags/ - It failed twice with some timeout error. However the second try might've been almost complete and takes around 500MB on my computer. So yes, that's quite a bit and if you have several plugins that amounts easily to multiple GB. So I totally understand that this is a waste of space (especially when comparing if to your Git repo that's only about 14MB large). But is this really a bad problem for you?
Have you tried checking out only the folders you're using? Maybe it's possible to just checkout trunk and the tags you need. Or draft some process that checks out SVN only during release.

However I've not used SVN in years so I'm not much help with this, sorry.

Can you use the GitHub repo to pull patch versions?

Composer allows git repos as package source, yes. However this requires the repo to be a composer package (it must have a composer.json) and this wouldn't have anything to do with WPackagist anymore.

I think you have not read what I propose properly, since this is not what I am suggesting.

I'm sorry. Can you please rephrase?

After rereading your proposal I understand it as follows:
You try to avoid changing minor releases by not releasing the minor in tags until you consider it stable enough and have moved development to the next minor release. So if 1.1 is the current minor then only 1.0 would be in tags and 1.1 would stay in trunk. Until you move on to 1.2 all changes to 1.1 will be available only in trunk. Only when moving on to 1.2 you'll copy 1.1 from trunk to tags/1.1. At this point it won't change again.

Is this correct?

If yes, then how do users access the latest minor? Will it be through trunk? If yes, this would lead to installing trunk versions which might result in unexpected updates to even newer versions. (Because the trunk zip file always includes the latest version)

[aurovrata]

Hey @pluspol sorry for the delayed response, was away travelling.

So in summary...

1. Delete old tags/ versions

Have you tried checking out only the folders you're using? Maybe it's possible to just checkout trunk and the tags you need. Or draft some process that checks out SVN only during release.

yes, that would be ideal really, but haven't figured out how to do that, couldn't find any documentation on this possibility.

Even deleting the local tags folder doesn't seem to work.

2. Use git for your packaging

Composer allows git repos as package source, yes. However this requires the repo to be a composer package (it must have a composer.json) and this wouldn't have anything to do with WPackagist anymore.

this is something I have not explored, if you are willing to help me figure this one out, then I feel this could be the best solution ?

3. Maintain only minor versions

If yes, then how do users access the latest minor? Will it be through trunk? If yes, this would lead to installing trunk versions which might result in unexpected updates to even newer versions. (Because the trunk zip file always includes the latest version)

Yes, you've understood that correctly.

the idea here was to allow users access to latest minor version (not patch) in the tags folder. The trunk would always be 1 minor version ahead.... which would not be accessible to your WPackagist script. A little but like linbux distros which have stable versions that don't included the latest packages. Not an ideal solution, but given the maturity of the plugin, your users would not loose out on much as the minor updates have very little functionality updates.

For updates that fix major issues that crop up with CF7 updates, I would release the minor updates on the tags folder on priority for your users to update.

[pluspol]

Hi @aurovrata ,
No reason for being sorry, I also can't respond that quickly, so also sorry from my side. :)

2. Use git for your packaging

Just to recap: This issue isn't specifically about your plugin but about some kinks in the whole ecosystem. So even when finding a better solution for your plugin we're left with many many others.

But yes, I'm happy to help with releasing your packages via composer:
If you want to release your plugins as composer packages then maybe release them officially. In this case they would be listed on https://packagist.org
Here is a tutorial how to do this:
https://www.w3resource.com/php/composer/create-publish-and-use-your-first-composer-package.php
Or on the official website: https://packagist.org/about

One thing to keep in mind:
Packagist.org strongly encourages packages to follow SemVer. I don't know if you're already using this approach.

[aurovrata]

If you want to release your plugins as composer packages then maybe release them officially. In this case they would be listed on https://packagist.org/

ok. My plugin isn't a standalone package as such (requiring CF7 plugin as well as the WP framework), I am assuming that isn't any issue?

Packagist.org strongly encourages packages to follow SemVer. I don't know if you're already using this approach.

yes this is already the case, Major.Minor.Patch (1.0.0).

I will register it and get back to you here.

[pluspol]

ok. My plugin isn't a standalone package as such (requiring CF7 plugin as well as the WP framework), I am assuming that isn't any issue?

In theory you would declare CF7 as requirement via the require section. However because it's not available through packagist.org you would also need to require the wpackagist registry to be used. But this is only possible via repositories key on root level: https://getcomposer.org/doc/04-schema.md#repositories
So I think you can only define it as a requirement in your documentation.
Other CF7 related composer packages also don't have any hardcoded dependency to CF7 (at least not in production):
https://packagist.org/?query=cf7

[NoelLH]

I do think the behavior that a plugin version without a tags folder return trunk as the download link fails in the users expectation of what they are going to download and should be changed. Because this is just incorrect behavior, eg some authors delete tags for older versions of their plugins and pointing these to trunk has very unintended consequences. If a plugin only supports trunk then the user should select the trunk version via their composer.json.

This part certainly sounds like something we could consider changing, but my hunch is this could be very disruptive to existing projects to change on the existing endpoints. I'm wondering if we should think about providing a v2. subdomain or similar – and updating the instructions for new users – so we can consider significantly different behaviour and a breaking change while phasing out the footgun for new users.

[aurovrata]

@pluspol greetings and a wonderful new year 2023 to you! Quick update on my progress. I am working on v5 of the plugin which has a big redesign of the UI editor as well as improvements in form rendering on the front-end.

My plan is to integrate the v5 into packagist as part of this new release. I hope to have a v5 out by end of Feb if progress continues as the current speed, but will start to integrate the RC versions into packagist so that you may start to test the integration in parallel for the first release.

[pluspol]

@pluspol greetings and a wonderful new year 2023 to you! Quick update on my progress. I am working on v5 of the plugin which has a big redesign of the UI editor as well as improvements in form rendering on the front-end.

My plan is to integrate the v5 into packagist as part of this new release. I hope to have a v5 out by end of Feb if progress continues as the current speed, but will start to integrate the RC versions into packagist so that you may start to test the integration in parallel for the first release.

Thanks. I also wish you a great new 2023!
Thanks for the update. I'm looking forward to the new release.