RFE: Change the master Alpha Beta setup

[leamas]

The current setup is that the three versions of our plugins lives in different branches (i. e., the master, Alpha and Beta branch). The approach with different branches was suggested at a time the idea was to use a modern system like Firefox's and flatpak's where build branches are directly visible to users.

Now, we have actually defined the there are exactly three branches or, really, three different sets of plugins. One alternative in this case could be to just drop the branches, and store the different set in a directory structure like

   metadata
         Alpha
             oesenc......xml
             oernc.......xml
             ...
         Beta
             oesenc......xml
             oernc.......xml
             ...
         master
             oesenc......xml
             oernc.......xml
             ...

The obvious advantage would be much simpler handling of pull requests at both ends of the wire. It should not affect end users in any way.

Contrary to my habits, filing this issue does not mean I'm about to file a PR. This definitely needs to be discussed before possible coding.

[rgleason]

I assume this would still support meta-url's in Alpha plugins? I find that very useful.

I believe this would not really change the plugin frontends, because it only affects how the xml and tarballs are handled after deployment to cloudsmith. However making this change after the process gets rolling might be more difficult.

The download catalog a single bigger catalog. Would that catalog include Alpha, Beta and master?
Since there is a single universal catalog, does that mean updates of Alpha, Beta and Master are not needed? ...that the entire universal catalog is fetched once and updated when options > plugins is selected? This would mean some changes and perhaps improvements to the OpenCPN PI Manager.

Does the plugin metadata. xml record get augmented with another field for the channel intended?
ie: Alpha, Beta, master? (with the meta-url's being restricted to Alpha?)

This would mean that there are some additional changes and thought required for the plugin frontends, with regard to that channel field - or does bdbcat simply add the field for "beta" or "master". This would mean that the xml's produced normally would run on Alpha meta-urls, or be accepted by bdbcat with a PR to the master branch, but since they have no channel field they would be treated as "Alpha" plugins. Then bdbcat could add the field for Beta and master?

No..., for consistency, I think a channel field is needed in the xml files coming from Cloudsmith. Would this field simply always have "Alpha" in it? So, there would be some small changes needed on the plugin frontend.

I think it might very well be easier with regard to PR's, but some thought needs to be given to when the designation master and Beta is added and who does it.

[leamas]

I assume this would still support meta-url's in Alpha plugins? I find that very useful.

There should no no changes like this. The xml is unchanged.

because it only affects how the xml and tarballs are handled after deployment to cloudsmith.

It does not affect anything of this. It only affects how to file and process PRs to the plugins project.

The download catalog a single bigger catalog. Would that catalog include Alpha, Beta and master

No. It's still three separate catalogs, available on a specific url, exactly as today. The only thing which will differ is the hardcoded urls to them in OpenCPN

[rgleason]

I see, Alpha.xml, Beta.xml, master.xml all in the OpenCPN/plugins/master branch
No changes to plugin frontends.
No changes to Opencpn PI Manager other than where to find the particular catalog and xml file.

I'm still thinking about this. So the Alpha meta-url's will still work ok... I think others better comment. The advantages of working out of one branch ... and the disadvantages.

Thought/concern: We had a bit of a meltdown in OpenCPN, when the xml file was not properly formatted. Have you got some internal checking in Opencpn that will prevent that? Maybe not allow downloads of plugins, but let users continue using Opencpn and the plugins they have? With a message, that indicates a problem with the catalog?

[rgleason]

Maybe we should feed OpenCPN a couple of bad catalogs and see what happens?

[rgleason]

One other thing,
I use a different plugins branch for creating an Alpha meta-url catalog ( rg-alpa) and the many plugin xml files are stored in that branches metadata directory. The ocpn_plugins.xml is created from that metadata directory and xml files and pushed up to my remote repository for the Alpha meta-url to read. That process will stay the same.

However for a Beta Plugin, what would you do?

1. Pull down the current Beta branch from opencpn/plugins?
2. Add your plugin xmls to the metadata directory alongside the ones you pulled down. Then use the script to make a new ocpn_plugin.xml. Rename it to 'beta.xml' or something.
3. Push to your remote plugins/Beta branch. Make a PR to opencpn/plugins beta branch.
4. Git pull the opencpn/plugins master branch which will update catalogs and metadata xml files.
5. Copy the Beta.xml to the master branch. (or does Bdbcat do this?)
6. I think we still need to have separate branches for Alpha, Beta and master in order to automatically build from metadata in each of those branches!
7. So I am not so sure simply putting the Alpha,xml, Beta.xml and master.xml in the master branch is going to change that much. --What have I got wrong about this?

[leamas]

However for a Beta Plugin, what would you do?

Basically, in the new regime there would only be the master branch, containing subdirectories with metadata files (master, Alpha and Beta). The master branch would also contain three different catalogs ocpn-plugins.xml, living in separate subdirectories.

So, a PR would be like a PR to any project. You add new/modified files to the Alpha directory, Dave accepts and rebuilds the Alpha catalog before committing.

Later on, Dave moves files, for example from Alpha to Beta, rebuilds the catalogs and commits.

These operations, submitting and handling PRs will be much simpler than today. Same goes for moving files between Alpha and Beta etc.

[rgleason]

OK, so Dave is doing the building of Alpha, Beta and Master catalogs.
You have not said you would have new directories under "metadata"!!! - to separate Alpha, Beta, master.

So we would simply git upstream pull master and then add our xml files to the appropriate metadata/sub-directory and then push origin master and using Git online make a PR to OpenCPN/plugins master branch?

We would not create the new Alpha, Master or Beta xmls and include them in the PR?

[leamas]

You have not said you would have new directories under "metadata"!!!

Actually, there is even a diagram in the initial comment ;)

So we would simply git upstream pull master and then add our xml files to the appropriate metadata/sub-directory and then push origin master and using Git online make a PR to OpenCPN/plugins master branch?

yes

We would not create the new Alpha, Master or Beta xmls and include them in the PR?

If I was Dave, I think it would be easier to rebuild myself before commit. That said, it works any way. And, I'm not Dave.

[rgleason]

Sorry... "store the different set in a directory structure like" read too fast.
Ok, I think I understand the ramifications. This is just changing operational procedures.

[rgleason]

Close?

[leamas]

Convert to discussion

[rgleason]

Alec, we can't convert to discussion easily. Can we close this now, since I believe you've done this?

[rgleason]

Alec can you convert this to a discussion, or close this? I can't

[leamas]

This is actually related to #818.

[rgleason]

Don't know where to comment on this.
I use Jon's bash script all the time to update opencpn/plugins/metadata from cloudsmith.
I find it simple flexible and direct.
This script will have to be updated if you are going to change the structure of master, Alpha and Beta.
Probably not a problem as long as it gets done.

[rgleason]

Also, I haven't used Alpha in a very very long time.

[jongough]

I use it all the time for delivery of my plugins. The alpha build occurs for every push/pull. The beta version is only for new version number in a non-master branch and for a pull into the master branch. Prod is generated by a new version created in the master branch. All need to be consistent with the newest changes progressing through alpha to beta to master/prod then full testing of changes can occur without creating an untested prod version.

[rgleason]

Agreed.