To be honest, I do not think that would be needed.
There would be no API/SPI changes in the patches, and yes I'm still
talking about Gradle Support specific patch, as I can manage that easily
on my own. So make a dependency on them would probably not worth the
effort. I'm just trying to keep this as simple as I could.
On 4/30/19 1:14 AM, Eric Barboni wrote:
Hi,
As a maven fanboy.
Once we vote on a release110_patch I think we can manage a "RELEASE110-PATCH1"
release base on the sources of the voted patch ? It will generate every bits but will
work I guess.
Regards
Eric
-----Message d'origine-----
De : Christian Lenz <christian.l...@gmx.net>
Envoyé : mardi 30 avril 2019 09:31
À : dev@netbeans.apache.org
Objet : AW: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
The stuff from Jaroslav sounds good to me 😊
Cheers
Chris
Von: Laszlo Kishalmi
Gesendet: Dienstag, 30. April 2019 08:07
An: dev@netbeans.apache.org
Betreff: Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
On 4/29/19 9:56 PM, Jaroslav Tulach wrote:
Hello Laszlo.
NetBeans used to be doing "patch releases" in the past. They consist
of generating new catalog with NBM files which then automatically
appears in the IDEs.
That is significantly easier than full release. In the context of Apache, I'd:
- create branch release110_patch1 rooted at release110
- selectively backported some fixes from master to that branch
- whenever a backport is made, update version numbers + dependencies
of affected modules only
Then we need to vote and release the source ZIP file and upload the
NBMs. No need to upload the binary ZIP file itself. IDE update center
catalog then needs to point to the new NBMs.
Yes, that's what I thought to be needed, then people turned this discussion
into a general release.
Dne neděle 28. dubna 2019 15:47:20 CEST, Laszlo Kishalmi napsal(a):
In order to be able to produce real time based releases our release
process and it's infrastructure have to be improved. Right now the
process consists of ~30 steps out of which ~15 require changes on the
actual code to be released. These includes:
* New Splash Screens (As you see on the list I'm trying to work on
this as well now)
That isn't needed.
* New versions to display in several places
That isn't needed either.
* Bumping the versions of the modules on two branches
Only bump versions of modules that are affected - only those will be
downloaded by Plugin Manager.
* API Signature sealing
We can live without this. At least our past experience shows that
there are very little API changes in the patch releases anyway.
Overall this could be significantly less work than regular release.
I'd suggest to start with a branch and a builder that builds source ZIP and
NBMs.
Then we can start testing the updated modules.
-jt
---------------------------------------------------------------------
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
