On 10/25/19 7:17 AM, Eric Barboni wrote:
Hi,
Needs to be simple and formal enough to be Apache compatible.
I'm afraid that if it's too complicated, a RM can cancel release vote because
if it may look simpler to merge some fix and revote. Or let the bug until the
next X.Y release.
And if a RM is more java oriented he may not see c++ or web issue as important
to deserve an update. (kind if Laszlo were not RM at the time maybe gradle
patch would have never been set)
Well that's not entirely true. Each release has it's own RM 11.1 and
11.2 happens to be Neil. A patch release can have a different RM. What
for example you are doing with the Maven Archetypes (btw thank you for
carry on that) are RM. It is the scope of such releases are way smaller
than releasing the whole IDE.
I would have created the Gradle patch release even if I was not the RM
for the whole IDE that time, though having two releases behind my back
certainly helped to have the confidence to walk though the path.
So anyone can step up coordinate and do a patch release of some modules
if the community approves that. When we are releasing the whole IDE the
RM has one orientation: the whole IDE.
Regards
Eric
-----Message d'origine-----
De : Laszlo Kishalmi <laszlo.kisha...@gmail.com>
Envoyé : vendredi 25 octobre 2019 14:52
À : dev@netbeans.apache.org
Objet : Re: [DISCUSS] Handling release updates
Well, the Gradle patch has been made in the following way:
1. The result of the release build has been further processed, extracting the
source files for the changed modules and the necessary files like NOTICE and
licenses.
2. So the output of the patch build was a small source zip and the
corresponding nbm-s as binary. The README had the instruction that how you need
to paths the existing source bundle with the new one to create the binaries.
3. We voted on the source files only
4. The nbms were overwritten in the distribution directory and the
updates.xml.gz was patched by hand.
Probably the ugliest part was the actual release of the nbms. In the future we
could create a separate update center for release updates and ship that
configured in the release. I think the new plugin portal infrastructure
probably could help, if that'd support multi tenancy.
On 10/23/19 5:51 AM, Neil C Smith wrote:
On Wed, 23 Oct 2019 at 13:47, Geertjan Wielenga <geert...@apache.org> wrote:
Will we really need to go through a vote process for this change?
IMO, yes - it's still a source change. And that's not quite the only
change required.
But there are other things we might want to make patches for too.
This thread was not meant to be specific to that one particular issue.
We need to work out a process for how we do this in future.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
