You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Laszlo Kishalmi <la...@gmail.com> on 2020/05/26 15:46:48 UTC
[DISCUSS] Patch Releases
Dear all,
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.
I would like to start a discussion here on patches as it already started
at https://github.com/apache/netbeans/pull/2156
So far I have the following questions to be discussed (feel free to extend):
1. How we prepare the source code of for the patch release in git?
2. How we prepare the source code of for the patch release?
Just to remember we are releasing source code officially, not
binaries. So what shall be the content, signatures, etc?
3. How shall we handle the module versions?
4. How shall we distribute the binaries?
5. How shall we handle the Maven artifacts?
As of me I see these as:
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.
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.
3. As far as I remember, with the ordinary release modules get their
version as <major>.<minor>.1, increasing third number would just do.
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.
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.
Re: [DISCUSS] Patch Releases
Posted by Laszlo Kishalmi <la...@gmail.com>.
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 <la...@gmail.com>
> Envoyé : mardi 26 mai 2020 18:44
> À : dev@netbeans.apache.org
> 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 <la...@gmail.com> 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: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
RE: [DISCUSS] Patch Releases
Posted by Eric Barboni <sk...@apache.org>.
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 <la...@gmail.com>
Envoyé : mardi 26 mai 2020 18:44
À : dev@netbeans.apache.org
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 <la...@gmail.com> 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: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Patch Releases
Posted by Laszlo Kishalmi <la...@gmail.com>.
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 <la...@gmail.com> 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: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Patch Releases
Posted by Neil C Smith <ne...@apache.org>.
On Tue, 26 May 2020 at 17:19, Neil C Smith <ne...@apache.org> wrote:
> 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.
One other thing to note, the NBMs there were jar signed with an ASF
signature, to at least show up as signed, if not trusted. Since 11.3,
Matthias' work on trusted update centres means that step won't be
needed, but careful splicing in of the right SHA into the catalog file
will be. This will still be a lot easier!
Likewise, from 12.0 the internal third-party UC no longer uses the
temporary key signing, but also uses the trusted mechanism, so we
should be able to update nb-javac modules without warning this time
around.
Being able to update the nb-javac wrappers to support the upcoming
Java 14 version is the key patch I can think of that we'll want to
push. (and then we can have the removing nb-javac in 12.1 discussion
thread! :-) )
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS] Patch Releases
Posted by Neil C Smith <ne...@apache.org>.
Hi,
Thanks for kicking this off!
On Tue, 26 May 2020 at 16:47, Laszlo Kishalmi <la...@gmail.com> 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: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists