MacOS plugin metadata file for OpenCPN 5.6.2 no longer validates
Closed this issue · 23 comments
@antipole2 is building an update of JavaScript_pi intended for 5.6.2.
The target uses the name darwin-wx315. This target name is no longer recognised and the validation for darwin fails.
target name darwin-wx315 was removed here:
Should this name be allowed again?
Yes.
Maybe the concept of leaving old plugins as they currently exist is not so good an idea, particularly in the case of a plugin that has been updated considerably such as javascript?
Mike. Can this be closed now?
This issue needs more work. Should plugins for OpenCPN 5.6.2 be available after they drop off the Cloudsmith lifecyle? If so we need to be able to compile the plugin for 5.6.2 and add the metadata to the master catalog. Still an issue with Darwin, I think.
Should plugins for OpenCPN 5.6.2 be available after they drop off the Cloudsmith lifecyce?
What does this mean, really? Are we not storing tagged releases more or less forever?
Will new updated versions continue to validate across the github gatekeeper and in PIM?
Expanding on this...
We have "old" entries in the catalog for example windows wx30 plugins and macos-wx315. When we add new entries using wx32 things should validate since we don't validate the complete catalog, only the changes. At least, we should. This means that the basic scheme is sound.
OTOH, when we do what Tony does, builds an old-style wx315 plugin this is an exceptional case. It should really only be used for some really hot fix on old plugins (the normal things is to persuade user to update old plugins and/or main OpenCPN in case of problems). That validation fails in this case is as I see it something we can live with, and much better then to allow outdated plugins based on wxwidgets < 3.2 without warnings.
the xsd file is by no means any "gatekeeper". It just emits warnings if plugins does not conform to some checks. In the end it is a manual decision to accept a catalog update or not.
Main opencpn will not change in next minor release (5.8.4?) and probably not in 5.10.0 either.
Alec, I differ, the xsd is a ":gatekeeper", to the plugin developer, it requires us to change the plugin in some way and rebuild everything if there is a failure. ...It certainly is a gatekeeper or filter, and that is its intent IMHO.
It just emits warnings if plugins does not conform to some checks
Normally the push is not accepted when there are failures.
Alec, I differ, the xsd is a ":gatekeeper", to the plugin developer, it requires us to change the plugin in some way and rebuild everything if there is a failure. ...It certainly is a gatekeeper or filter, and that is its intent IMHO.
If there are warnings from the validation which are not justified, you could just make a PR anyway and make a note in the PR why you think it should be accepted despite the warnings. Dave will evaluate this. In the case this is a plugin for say Buster or windows-wx30 he will happily merge despite these warnings.
Once again: we could either accept wx315 plugins or not. If we accept them it means we would accept "new" plugins linked to wx315. This would then be a false negative, the test succeeds despite the bug.
If we don't accept them we will get a warning when we use wx-315. In the normal case this is as it should, but when making "old" plugins it's a false positive i. e. a warning despite that there is no bug.
Given all this, we prefer the false positives which we can evaluate over the false negatives which would mean that bugs passed without any warnings.
The same applies to windows/wx30, buster/wx30, etc.
What does this mean, really? Are we not storing tagged releases more or less forever?
Cloudsmith has new rules. Previously you nominated the number of packages that would be retained. For instance - calculator_pi had 100 packages. As more builds were made any packages in excess of 100 would be deleted. No artifacts for the master catalog if they are wxWidgets 3.1 and they have been pushed out by wxWidgets 3.2.
Now we seem to need a subscription?
https://help.cloudsmith.io/docs/retention-lifecycle
What is the retention rule for the Cloudsmith core package we now use?
I have never really understood this completely. Are you saying that the default retention rule is to store max 100 packages i. e. if there is not retention rule we will only have the 100 latest tarballs available?
we will only have the 100 latest tarballs available?
That is true for calculator_pi. Polar_pi seems to be using a higher number (528). But how this affects any new plugins that are added is not known. And I think the metadata file counts as a package as well as the tarball.
@rgleason : Have you had any contact with Cloudsmith about the allowances?
When I read what I can see it seems that without retention rules just everything is left, nothing is ever removed. Am I wrong?
All my plugins have retention rules.
Looking at OSS usage, for the OpenCPN organisation, we are now at:
Storage
42.149%
21.1 GB / 50.0 GB
So for new plugins it will be the storage aspect that could have an impact eventually. At present no problem with this.
The developer manual needs an update!
So for new plugins it will be the storage aspect that could have an impact eventually. At present no problem with this
And in the end, storing outside tghe opencpn organization is trivial, some of us already do. So again, the 50GB limit is no problem.
All my plugins have retention rules.
Yes, we documented the use of these in the manual. But if we cannot define them, is this actually a problem besides that the repo becomes large and hard to navigate in?
The developer manual needs an update!
Indeed. Something you can do?
I just saw this. Yes, open source no longer has access to retention rules. This was changed about 3-4 months ago.
I have not contacted support about it, but have been coasting....
Alec wrote:
If there are warnings from the validation which are not justified, you could just make a PR anyway and make a note in the PR why you think it should be accepted despite the warnings. Dave will evaluate this. In the case this is a plugin for say Buster or windows-wx30 he will happily merge despite these warnings.
This is a good point!!!
At least I am aware of the problem of the lifecycle and can advise a user of 5.6.2 accordingly. Upgrade!
I will edit the Developer Manual in the next day or two. Closing.