Hi, As a maven fanboy. Once we vote on a release110_patch I think we can manage a "RELEASE110-PATCH1" release base on the sources of the voted patch ? It will generate every bits but will work I guess.
Regards Eric -----Message d'origine----- De : Christian Lenz <christian.l...@gmx.net> Envoyé : mardi 30 avril 2019 09:31 À : dev@netbeans.apache.org Objet : AW: [DISCUSS} Apache NetBeans Gradle Patch 1 Release The stuff from Jaroslav sounds good to me 😊 Cheers Chris Von: Laszlo Kishalmi Gesendet: Dienstag, 30. April 2019 08:07 An: dev@netbeans.apache.org Betreff: Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release On 4/29/19 9:56 PM, Jaroslav Tulach wrote: > 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. > Yes, that's what I thought to be needed, then people turned this discussion into a general release. > 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 > > > --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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
