Hi, Just bringing the discussion part of https://github.com/apache/netbeans-website/pull/473 on to here.
Matthias correctly pointed out in the above PR that we've not kept redirects for the master branch update centre and plugin portal always in line with the current release branch. Not just for 12.0 - probably over each release for the last year. This is one reason a current issue with the plugin portal may have gone unnoticed. Over the last year or two we've moved to having all inbound links from the IDE come in under https://netbeans.apache.org/nb. This has a variety of benefits, one being we can easily manage redirecting things to the right place in https://github.com/apache/netbeans-website/blob/master/netbeans.apache.org/src/content/.htaccess Useful, particularly during transition from Oracle to Apache infrastructure, to change things without requiring IDE updates. It has also given us predictable links for update centre and plugin portal for each release and master, even with underlying changes. After 12.0 is released we should probably make the following 3 changes, only the third part of which was really cause for discussion on the PR. # Stage 1 Change the dev redirects in the .htaccess to - Redirect 302 /nb/updates/dev/ https://netbeans-vm.apache.org/uc/dev/ Redirect 302 /nb/plugins/dev/ https://plugins.netbeans.apache.org/data/dev/ This will require setting up /dev endpoints for the UC on the VM and on the plugin portal. Initially as symlinks for 12.0? # Stage 2 Once the above is working, we can remove a lot of the redirects and move everything up a level - then we have no need to update the .htaccess for each release - Redirect 302 /nb/updates/ https://netbeans-vm.apache.org/uc/ Redirect 302 /nb/plugins/ https://plugins.netbeans.apache.org/data/ We could also just proxy those links from those places without redirect? Might help with issue of being blocked when processing a lot of updates? # Stage 3 We can then make a decision on what update centre and plugin portal catalogues make sense for dev builds. IMO, and the bit that really caused discussion, we adjust the latest master build on Jenkins to serve the NBMs and point at that (via the VM). I think this is what happened before the Apache transition? https://builds.apache.org/view/M-R/view/NetBeans/job/netbeans-TLP/job/netbeans/job/master/lastSuccessfulBuild/artifact/ Antonio raised concerns on the PR that infra might not appreciate that - obviously we don't have to do it, but considering we've been distributing beta builds direct from Jenkins, it's probably a very minor increase in bandwidth. Would it actually be useful? We could also consider a dev / next specific section on the plugin portal to allow plugin authors to test with master? Or to try new plugin portal features? Sorry about the long email about what feel like minor changes, but given the discussion on the PR, be good to know this is what we're heading for, or not. Losing track of how much of this has happened by release manager convention, and how much is an actual plan! :-) Best wishes, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
