Hi Laszlo, Answering for point 5 Changing version of changed module is not enough because, other modules will depend on modified dependencies and all pom should be altered with new version. Checking that is long and error prone. Depends on the modules that change. Around 800 artifacts to check. For me to get maven artefacts the following steps : getting release source applying patch and rebuilding maven artefacts full stack with bumped version.
Hard version like RELEASE120 is the only way for now to know its Apache NetBeans 12.0 and will break the wizards, openide.io 1.57 is unrelated to 12.0 and in module you depends on precise artefacts not cluster. Hard to manage and upgrade. I guess this was not done in Oracle era. By the way, the patch is available in uc, your platform will be updated on first run. Best Regards Eric -----Message d'origine----- De : Laszlo Kishalmi <[email protected]> Envoyé : mardi 26 mai 2020 18:44 À : [email protected] Objet : Re: [DISCUSS] Patch Releases On 5/26/20 9:19 AM, Neil C Smith wrote: > Hi, > > Thanks for kicking this off! > > On Tue, 26 May 2020 at 16:47, Laszlo Kishalmi <[email protected]> > wrote: >> In the past we were able to release patches to the IDE. I'm sure that >> in the future we shall be able to release patches for 12.0 LTS as well. > Well, we already have for 11.0 and 11.2. You did the former I believe. > > Comments inline, based on the fact we discussed this already a fair > bit doing 11.2-u1. Answering your questions based on what I RM'd for > that. That is far from a canonical approach, and open to discussion. > But it might also be better not to start from scratch? > >> 1. PR-s shall be marked "Cherry pick" for the patch release. The RM for >> the patch release shall merge these patches to the release branch. >> The RM shall make sure that, along these patches, the affected >> module versions get properly adjusted. > PRs to master were marked with "Cherry Pick". After they went into > master, someone (ideally the person who made the master PR) opened a > second PR against the release branch. This ensures the code and any > potential differences (hopefully minor) to what has gone into master > is CI tested and reviewed against the release branch (eg. we push > sigtest files into the release branch after release). Sounds good. > >> 2. As of the source code release, I'd do create a zip file containing >> the changed files between the previous (patch) release and the >> current release (I boldly assume that there wouldn't be file >> deletion in a patch release). That would be the content of the >> release, and that would be the artifact to be voted on. > Disagree. The Jenkins build creates and checks the source zip against > a tag on release branch. It's better and easier to vote on the full > updated source and keep our processes consistent, then pick and choose > what binaries need to be updated where. Cool, sounds fine, probably I shall check the new features of the release build process sometime... > >> 3. As far as I remember, with the ordinary release modules get their >> version as <major>.<minor>.1, increasing third number would just do. > More than "just do", it's really important. Version needs to > increase, but not get ahead of master. Every module gets minor > increment in master before merge window reopens. Therefore this is > one reason the PR to master and to release branch may differ. > > Two PRs for same fix to compare from 11.2-u1, noting version > differences - > > https://github.com/apache/netbeans/pull/1604 (master) > https://github.com/apache/netbeans/pull/1659 (release112) > >> 4. We shall distribute the changed modules through the release update >> center. I do not know if it worth the hassle to build installers >> from the patch. > We didn't bother with installers or full binaries. We just provided > required update nbms on the mirrors, and manually adjusted the catalog > file on the NetBeans VM to point at the right files. > > What we actually pushed on to the mirrors is all at > https://archive.apache.org/dist/netbeans/netbeans/11.2-u1/ Note the > very limited NBMs and only full source zip - no installers or > binaries. > > Automating the splicing of the new NBMs into the existing catalog on > the VM would be nice, but it's not too much work. > >> 5. I must confess, that I'm not into the Maven artifact business of >> NetBeans, so I might sound silly here. The creation of a BOM for >> RELEASE120-1 shall be possible even if that would be a hand crafted >> one from RELEASE120 generated BOM. Also that might be not even >> needed as whoever builds on RELEASE120 have the option to use a >> specific version of a module anyway, so I'd leave the responsibility >> for updating maven based NetBeans Platform applications in the hand >> of their maintainer. This also means that we would only upload >> modules that changed to Maven Central. > This is the spanner in the works! :-) I have no idea how to handle > this. Eric and I discussed a bit around 11.2 updates, but don't think > we ever did push those updates to Maven. > > Ideally IMO the cluster POMs (which are effectively a bill of > materials?) would be marked with eg. RELEASE120 as version, and the > modules themselves would use spec versions? > > 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 > > > --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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
