Hello Laszlo. NetBeans used to be doing "patch releases" in the past. They consist of generating new catalog with NBM files which then automatically appears in the IDEs.
That is significantly easier than full release. In the context of Apache, I'd: - create branch release110_patch1 rooted at release110 - selectively backported some fixes from master to that branch - whenever a backport is made, update version numbers + dependencies of affected modules only Then we need to vote and release the source ZIP file and upload the NBMs. No need to upload the binary ZIP file itself. IDE update center catalog then needs to point to the new NBMs. Dne neděle 28. dubna 2019 15:47:20 CEST, Laszlo Kishalmi napsal(a): > In order to be able to produce real time based releases our release > process and it's infrastructure have to be improved. Right now the > process consists of ~30 steps out of which ~15 require changes on the > actual code to be released. These includes: > > * New Splash Screens (As you see on the list I'm trying to work on > this as well now) That isn't needed. > * New versions to display in several places That isn't needed either. > * Bumping the versions of the modules on two branches Only bump versions of modules that are affected - only those will be downloaded by Plugin Manager. > * API Signature sealing We can live without this. At least our past experience shows that there are very little API changes in the patch releases anyway. Overall this could be significantly less work than regular release. I'd suggest to start with a branch and a builder that builds source ZIP and NBMs. Then we can start testing the updated modules. -jt --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
