Hi, Sorry for the disabled jobs. Was not intended. Thought it was because too many scan last week.
If we can assume that release160 is ok then you have to check for https://github.com/apache/netbeans-jenkins-lib/blob/master/meta/netbeansrelease.json section release160 and a adapt to add the new commit hash (should be a tag ) (with name u1 ) and maven version "mavenversion": "RELEASE160-u1" if a new maven is needed, vsixVersion if needed build job build the last artefacts but the RM can choose to not call a vote on them For the BOM approach , could be nice but I guess we should use the apache groupId, (org.apache.netbeans) otherwise we will have our RELEASE* in the path to get a proper last version. Best Regards Eric -----Message d'origine----- De : Neil C Smith <neilcsm...@apache.org> Envoyé : lundi 28 novembre 2022 12:26 À : Michael Bien <mbie...@gmail.com> Cc : dev@netbeans.apache.org Objet : Re: [DISCUSSION] Gradle Patch Release for NetBeans 16 On Mon, 28 Nov 2022 at 10:22, Michael Bien <mbie...@gmail.com> wrote: > > On 28.11.22 10:16, Neil C Smith wrote: > > On Mon, 28 Nov 2022 at 01:47, Michael Bien <mbie...@gmail.com> wrote: > >> I think I like this approach. Just to be sure I understand: this > >> also means there will be no RELEASE161 artifacts in maven-central? > >> The only binaries of this release are the updated gradle modules in > >> the update center? > > I can't say I "like" the approach. :-) It's the one we have, and > > it's a bit of a pain, which is why we've not done it very often! > > Yeah I can see that. I just think it is good to have a > more-lightweight way of releasing a patch if there is the need. If you think my comment was based on it being too lightweight, you've misunderstood what I meant! The need to manually splice two update catalogs, one for testing and voting, then the main one for releasing, is a pain. At least we don't have to JAR sign the NBMs any more! But yes, practice, documenting, and (ideally) some automation would be good. particularly if we need to ship high priority updates. > Eric knows since he told me how to filter the versions you see on the > new NB application wizard. There is also a 120-1 btw ;) That was for a different reason, I believe. Looks like the u1 was requested by Jaroslav - https://lists.apache.org/thread/pn9w856x14gqjj4dm9949sgh5vjnod5n Discussion of BOM there too. Another old discussion on update process which might be of interest (also bit on BOM) - https://lists.apache.org/thread/ysvpkxnnjp22rdv040msvh4o14xn2lds > There is probably only one u1 since there was only one update to the > LTS release, right? There were two. There was also an 11.2-u1 which didn't get a Maven update. There were earlier ones too, but not listed in netbeansrelease.json as the build process changed with 11.2, which also changed the patch release process to that outlined in the above threads. Not that we've done that for a while. And it also appears that I said the splicing of the catalog is "not too much work" - I may have changed my mind! :-) > I bet you are already thinking about how to preload the update in your > codelerity NB bundles :) Not unless we decide to release an updated Apache NetBeans binary zip. Our installers will always use the contents of the latest binary zip release, and you can do a binary comparison of the contents (a deliberate design decision). Best wishes, Neil --------------------------------------------------------------------- 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
