Create a 'current' Update site on the documenation pages

[keinhaar]

For easier and faster updates, the update site should be on the plugins homepage.
Also it should not contain the version number, because all those pages need to be updated after a new release, which makes a lot of extra work, and will never happen at the same time as the release.

[niloc132]

We can change the current release layout if you'd like - but it exists that way so that so that we can stage a release before sending it to the plugin site, and continue to allow downloads of old plugins in case of a regression/etc.

Keep in mind that there will be limits on github to how much data can be added to history this way - deleting a file doesn't remove it from history (unless each build is force pushed to rewrite the site branch in history), and github will limit file size and total repo size (files: warn at 50mb, fail at 100mb, repo strongly urged to be limited to 5gb). Git LFS is typically a better choice for checking in binary files, but costs money per org.

https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-large-files-on-github

We do have a webhook intended to signal that a nightly build is ready to be deployed (and it should be unzipped on the server), but it wasn't finished being set up, nor did we generalize it for releases (listen for the release hook, etc). If we'd like to change the pattern for releases so that old releases are inaccessible and RCs are only available by downloading the repository, we can do that as well - let me know.

https://github.com/Vertispan/gwtproject.org/blob/main/plugins/hook-deploy.sh

[keinhaar]

OK, so what exactly are the steps to get an release out on plugins.gwtproject.org?
Last Release was done by you and @protoism (if i'm right??), so i don't know anything about it.
I would really like to fix problems faster in case of broken plugin as in issue #496.
Also, it should not be nessesary to update lots of additional pages to get the linked versions right. For example
https://www.gwtproject.org/usingeclipse.html still links to the old version 4.0.0 of the plugin.
Keeping old versions available is good, but we really need a "current" or "latest" folder for the current release.

My proposal is to have a directory structure like this under https://plugins.gwtproject.org/eclipse/:

repo/
  site/                    ( the COMPOSITE UPDATE SITEs (references the current folder of eclipse plugin and the SDKs) )
    current/      
  gwt-eclipse-plugin/      ( the GWT PLUGINs update sites )
    current/
    4.0.0/
    4.1.0/
  gwt-sdk-plugins/         ( the SDK PLUGINS update sites )
    current/
    4.0.0/
    4.1.0/

This would allow us to release plugin and sdks independently from each other, while the eclipse user can still install both from the composite update site.
All documentation and the marketplace entry could then link to https://plugins.gwtproject.org/eclipse/repo/site/current

[niloc132]

Adding current//latest/ makes good sense, and should probably be a manual part of any release (don't want to push a RC and have everyone get it right away, nor push 4.2 then 4.1.2 and have 4.1.2 be "current"). Pick the name and I'll make the soft link right now.

I'd propose that this soft link be in the same directory as https://plugins.gwtproject.org/eclipse/gwt-eclipse-plugin/ so that any user browsing can see specific versions or the "get me the current stable" right away. (Aside: the new RC is already deployed to that link, as of a few hrs ago.)

I agree on faster releases, but when I tried to build these webhooks I needed updates to go with it so we could test and keep moving, but that didn't happen... at least not on a time scale when I still knew how all of this still worked.