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
