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). > 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. > 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
