I see now, so every module version in Maven would be RELEASE120.
That's bad, shall be changed in the future.
I see the potential pain updating the dependencies, though it might be
possible to issue a module with RELEASE120.1 version which depends on
RELEASE120 versions.
At this point, I'd just skip creating Maven artifacts for patch releases.
On 5/27/20 5:42 AM, Eric Barboni wrote:
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
---------------------------------------------------------------------
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
