Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Right now it is the actual whole files that have been changed. In contrast of git patch it does not support file deletions, but as this is just a patch there is no whole file deletion in there. I've thought that reviewing simple files is probably simpler, than reviewing an actual patch. So the build instructions would be something like: wget http://mirror.metrocast.net/apache/incubator/netbeans/incubating-netbeans/incubating-11.0/incubating-netbeans-11.0-source.zip wget https://builds.apache.org/job/netbeans-gradle-patch-release/lastSuccessfulBuild/artifact/dist/netbeans-11.0-gradle-patch-1-source.zip mkdir netbeans -src unzip incubating-netbeans-11.0-source.zip -d netbeans-src unzip -o netbeans-11.0-gradle-patch-1-source.zip -d netbeans-src cd netbeans-src ant On 5/13/19 12:42 AM, Geertjan Wielenga wrote: Excellent! Can you also describe the optimal way of overwriting the files? I.e., is in here an actual patch which we can via a git command incorporate into a clone of the main repo? Gj On Sun, 12 May 2019 at 19:38, Laszlo Kishalmi wrote: Dear all, I was able to assemble something. Please check it and share your thought: https://builds.apache.org/job/netbeans-gradle-patch-release/lastSuccessfulBuild/artifact/dist/netbeans-11.0-gradle-patch-1-source.zip It is not the final one though. In order to build that you need to download the 11.0 sources and overwrite the files from the patch source. The actual patch is a bit more than it normally should as it contains another PR-1206 ( https://github.com/apache/netbeans/pull/1206) in order to be able to be buildable with the recent infrastructure changes around netbeans.org. So what's remaining: * Increase the impl versiosns of the changed modules * Extend the build instructions in README.MD * Call for a vote * Update the hosted patches: 1. I'd overwrite the nbms in the release area of 11.0 2. Wait 24 hours for the mirrors to pick up 3. Update the changed sections in update.xml.gz on the netbeans-vm * Send announcement to the netbeans announcement list, as it is just a patch, I do not think we need to announce it on global Apache level, do we? On 4/26/19 10:57 PM, Laszlo Kishalmi wrote: Dear all, As Gradle was a new out-of-the box feature, I've received some issues/feedback. I've already fixed some of them. I would like to do a release of those changes. Those fixes might be not that important, but what I'm really curious, that actually can we, and how can we roll out such a partial patch release? My plan is the following: 1. Branch the current release into something like: release110-gradle-patch-1 2. Cherry Pick the required changes 3. Increase the patch version (3rd number on the affected modules (I guess only gradle and gradle.java) 4. Set up a jenkins job for that branch to release. 5. The release artifacts would be 1. The new nbm modules from gradle and gradle.java 2. The source artifact would contain those module sources only. 3. I do not know what to put in there exactly: 1. The sources of the two modules keeping the directory structure. so that would be in groovy/gradle and groovy/gradle.java 2. LICENSE and NOTICE files 3. Is there a way to generate the DEPENDENCIES file only for two modules? 6. Do the PGP signing with my key 7. Start a vote on the artifacts 8. If the vote would be successful: 1. I'd upload the source artifact next to our release 11.0 one. 2. I'd upload the binary nbm-s into the 11.0 distribution UC 3. I do not know how to updates.xml, probably I keep the one generated for the whole NB from step 5 and overwrite the current one. 9. Again I do not know how much announcement we shall make with this release, maybe a just our announcement list would be enough. Please think it through! Is this feasible, what else shall be done, do I have some misconceptions, etc. ? Also would like to have a peer feedback from our Release Manager Emilian. Thank you! Laszlo Kishalmi
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Excellent! Can you also describe the optimal way of overwriting the files? I.e., is in here an actual patch which we can via a git command incorporate into a clone of the main repo? Gj On Sun, 12 May 2019 at 19:38, Laszlo Kishalmi wrote: > Dear all, > > I was able to assemble something. Please check it and share your > thought: > > https://builds.apache.org/job/netbeans-gradle-patch-release/lastSuccessfulBuild/artifact/dist/netbeans-11.0-gradle-patch-1-source.zip > > It is not the final one though. > > In order to build that you need to download the 11.0 sources and > overwrite the files from the patch source. The actual patch is a bit > more than it normally should as it contains another PR-1206 ( > https://github.com/apache/netbeans/pull/1206) in order to be able to be > buildable with the recent infrastructure changes around netbeans.org. > > So what's remaining: > > * Increase the impl versiosns of the changed modules > * Extend the build instructions in README.MD > * Call for a vote > * Update the hosted patches: > 1. I'd overwrite the nbms in the release area of 11.0 > 2. Wait 24 hours for the mirrors to pick up > 3. Update the changed sections in update.xml.gz on the netbeans-vm > * Send announcement to the netbeans announcement list, as it is just a > patch, I do not think we need to announce it on global Apache level, > do we? > > > On 4/26/19 10:57 PM, Laszlo Kishalmi wrote: > > > > Dear all, > > > > As Gradle was a new out-of-the box feature, I've received some > > issues/feedback. I've already fixed some of them. > > > > I would like to do a release of those changes. Those fixes might be > > not that important, but what I'm really curious, that actually can we, > > and how can we roll out such a partial patch release? > > > > My plan is the following: > > > > 1. Branch the current release into something like: > > release110-gradle-patch-1 > > 2. Cherry Pick the required changes > > 3. Increase the patch version (3rd number on the affected modules (I > > guess only gradle and gradle.java) > > 4. Set up a jenkins job for that branch to release. > > 5. The release artifacts would be > > 1. The new nbm modules from gradle and gradle.java > > 2. The source artifact would contain those module sources only. > > 3. I do not know what to put in there exactly: > > 1. The sources of the two modules keeping the directory > > structure. so that would be in groovy/gradle and > > groovy/gradle.java > > 2. LICENSE and NOTICE files > > 3. Is there a way to generate the DEPENDENCIES file only for > > two modules? > > 6. Do the PGP signing with my key > > 7. Start a vote on the artifacts > > 8. If the vote would be successful: > > 1. I'd upload the source artifact next to our release 11.0 one. > > 2. I'd upload the binary nbm-s into the 11.0 distribution UC > > 3. I do not know how to updates.xml, probably I keep the one > > generated for the whole NB from step 5 and overwrite the > > current one. > > 9. Again I do not know how much announcement we shall make with this > > release, maybe a just our announcement list would be enough. > > > > Please think it through! Is this feasible, what else shall be done, do > > I have some misconceptions, etc. ? > > > > Also would like to have a peer feedback from our Release Manager Emilian. > > > > Thank you! > > > > Laszlo Kishalmi > > >
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Dear all, I was able to assemble something. Please check it and share your thought: https://builds.apache.org/job/netbeans-gradle-patch-release/lastSuccessfulBuild/artifact/dist/netbeans-11.0-gradle-patch-1-source.zip It is not the final one though. In order to build that you need to download the 11.0 sources and overwrite the files from the patch source. The actual patch is a bit more than it normally should as it contains another PR-1206 ( https://github.com/apache/netbeans/pull/1206) in order to be able to be buildable with the recent infrastructure changes around netbeans.org. So what's remaining: * Increase the impl versiosns of the changed modules * Extend the build instructions in README.MD * Call for a vote * Update the hosted patches: 1. I'd overwrite the nbms in the release area of 11.0 2. Wait 24 hours for the mirrors to pick up 3. Update the changed sections in update.xml.gz on the netbeans-vm * Send announcement to the netbeans announcement list, as it is just a patch, I do not think we need to announce it on global Apache level, do we? On 4/26/19 10:57 PM, Laszlo Kishalmi wrote: Dear all, As Gradle was a new out-of-the box feature, I've received some issues/feedback. I've already fixed some of them. I would like to do a release of those changes. Those fixes might be not that important, but what I'm really curious, that actually can we, and how can we roll out such a partial patch release? My plan is the following: 1. Branch the current release into something like: release110-gradle-patch-1 2. Cherry Pick the required changes 3. Increase the patch version (3rd number on the affected modules (I guess only gradle and gradle.java) 4. Set up a jenkins job for that branch to release. 5. The release artifacts would be 1. The new nbm modules from gradle and gradle.java 2. The source artifact would contain those module sources only. 3. I do not know what to put in there exactly: 1. The sources of the two modules keeping the directory structure. so that would be in groovy/gradle and groovy/gradle.java 2. LICENSE and NOTICE files 3. Is there a way to generate the DEPENDENCIES file only for two modules? 6. Do the PGP signing with my key 7. Start a vote on the artifacts 8. If the vote would be successful: 1. I'd upload the source artifact next to our release 11.0 one. 2. I'd upload the binary nbm-s into the 11.0 distribution UC 3. I do not know how to updates.xml, probably I keep the one generated for the whole NB from step 5 and overwrite the current one. 9. Again I do not know how much announcement we shall make with this release, maybe a just our announcement list would be enough. Please think it through! Is this feasible, what else shall be done, do I have some misconceptions, etc. ? Also would like to have a peer feedback from our Release Manager Emilian. Thank you! Laszlo Kishalmi
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
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 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
RE: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
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 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
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
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
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. 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
Re: Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Some of this I believe is already leveraged but just restating in current conversation as applicable. Seem to recall the “temple” Jira ticket with all the steps define for a release previously. https://issues.apache.org/jira/browse/NETBEANS-2052 (https://issues.apache.org/jira/browse/NETBEANS-2052?jql=text%20~%20%2211.0%22) is created. Maybe when a release is initially planned, it needs to be cloned (adding any new sub tasks as changes) and assigned to release manage. As candidates tickets for inclusion are identified they are linked in the release ticket, marked in the candidate ticket, inclusion of applicable pull requests where applicable. For patch releases, assume similar clone be created but maybe with a subset of the tasks to reduce work for the full release. What kind of tasks do you think are fully needed in a patch release? Are there any ways to link a JIRA task with a build requests in some way so that when one or the other is triggered (maybe some state change) it would start a give build to automate some of the tasks? Assume at a minimum some build types may need monitoring to ensure good build quality to an acceptable level. Maybe an extra subtask of “running unit test suite x” with passing at a minimum? Eric Bresie ebre...@gmail.com > On April 28, 2019 at 8:47:20 AM CDT, Laszlo Kishalmi > wrote: > Well, I'd put the time based releases aside for a while with the > following comment on that and stick to the original topic of this > discussion. > > 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) > * New versions to display in several places > * Bumping the versions of the modules on two branches > * API Signature sealing > > We need to automate these things first (or talk about, if we could skip > some of the steps), then we shall be able to discuss time based releases. > > In theory we shall reach a point when we have a build job in Jenkins > that input is a git revision and a release version (like 12.0) and it > would create, a branch with a source and binaries with the correct > version numbers, branding, etc. and also bump versions on the source branch. > > I'd probably itemize the tasks what should be done for this in JIRA and > create a WIKI page for that as well. > > I would just concentrate on releasing a patch with the least but > sufficient effort right now. > > > On 4/28/19 1:20 AM, Neil C Smith wrote: > > On Sun, 28 Apr 2019, 07:44 Matthias Bläsing, > > wrote: > > > > > at some point in the past we said, that we wanted to do time based > > > releases and I would still follow that thinking. > > > > > > I would branch any release of master, as late as possible, (not some > > > random other base), do testing and only minimal cherry-picking, > > > release. Repeat X months later. > > > > > > That way we know: > > > > > > - when a release is due > > > - what will be in the release (the state of master) > > > > > +1 to this. At some point in the initial thread on time-based releases Jan > > also suggested merge windows for master to keep cherry picking minimal. I > > think being stricter about what gets merged to master and when might be > > required? > > > > I was looking around the NB11 release process a while ago, and wondered > > about feasibility of making some of those release branch commits be > > configurable in the master build instead? That way branching could happen > > more easily later in the schedule, after testing for final beta maybe? > > > > Still think next should be NB 12.0 to do time-based releasing properly! As > > Matthias said, you don't know for sure what's in it until you freeze > > master, so how do you know it's major or minor? > > > > 11.1, 12.1 etc. could be reserved for patch updates where a new full binary > > download might be warranted? There using release branch possibly makes more > > sense. > > > > Best wishes, > > > > Neil > >
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
On 4/28/19 7:01 AM, Matthias Bläsing wrote: Hi, Am Sonntag, den 28.04.2019, 06:47 -0700 schrieb Laszlo Kishalmi: We need to automate these things first (or talk about, if we could skip some of the steps), then we shall be able to discuss time based releases. so we invalidate the decission from the past? Sorry, but I think we should discuss it some more. I do not think that we shall invalidate that we would like to do timely releases. That's doable, however, as I wrote in my 11.0 release feedback, with the current structure it requires considerable amount of human resource from the Release Manager. IMHO we can do 4 releases per year, with the process/setup we have right now. It is nothing wrong with the vision of having time based releases by simply cutting the master branch at a given point of time. It is just we need to get there somehow. I did not follow the release in detail, but do we have a detailed list of steps for a release? Well the Release Steps are documented here for * 11.0: https://issues.apache.org/jira/browse/NETBEANS-2052 * 10.0: https://issues.apache.org/jira/browse/NETBEANS-1321 My feeling is, that at least parts are so complicated, just because. Antonio for example is already on the problem of generating the splash screen. Yes Antonio is very kind helping with the splash screen, though I still need to convince NetBeans either the build process or the bootstrap code to make a good use of that. Many steps will also need to be done for a partitial release, so what do we gain from partitial/patch releases? Well, the number of release steps are much smaller (9, actually 8), as well as the affected codebase, so it can be rolled out quicker. Maybe a few hours of work + the VOTING. Greetings Matthias - 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
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Hi, Am Sonntag, den 28.04.2019, 06:47 -0700 schrieb Laszlo Kishalmi: > > We need to automate these things first (or talk about, if we could skip > some of the steps), then we shall be able to discuss time based releases. > so we invalidate the decission from the past? Sorry, but I think we should discuss it some more. I did not follow the release in detail, but do we have a detailed list of steps for a release? My feeling is, that at least parts are so complicated, just because. Antonio for example is already on the problem of generating the splash screen. Many steps will also need to be done for a partitial release, so what do we gain from partitial/patch releases? Greetings Matthias - 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
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Well, I'd put the time based releases aside for a while with the following comment on that and stick to the original topic of this discussion. 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) * New versions to display in several places * Bumping the versions of the modules on two branches * API Signature sealing We need to automate these things first (or talk about, if we could skip some of the steps), then we shall be able to discuss time based releases. In theory we shall reach a point when we have a build job in Jenkins that input is a git revision and a release version (like 12.0) and it would create, a branch with a source and binaries with the correct version numbers, branding, etc. and also bump versions on the source branch. I'd probably itemize the tasks what should be done for this in JIRA and create a WIKI page for that as well. I would just concentrate on releasing a patch with the least but sufficient effort right now. On 4/28/19 1:20 AM, Neil C Smith wrote: On Sun, 28 Apr 2019, 07:44 Matthias Bläsing, wrote: at some point in the past we said, that we wanted to do time based releases and I would still follow that thinking. I would branch any release of master, as late as possible, (not some random other base), do testing and only minimal cherry-picking, release. Repeat X months later. That way we know: - when a release is due - what will be in the release (the state of master) +1 to this. At some point in the initial thread on time-based releases Jan also suggested merge windows for master to keep cherry picking minimal. I think being stricter about what gets merged to master and when might be required? I was looking around the NB11 release process a while ago, and wondered about feasibility of making some of those release branch commits be configurable in the master build instead? That way branching could happen more easily later in the schedule, after testing for final beta maybe? Still think next should be NB 12.0 to do time-based releasing properly! As Matthias said, you don't know for sure what's in it until you freeze master, so how do you know it's major or minor? 11.1, 12.1 etc. could be reserved for patch updates where a new full binary download might be warranted? There using release branch possibly makes more sense. Best wishes, Neil
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
On Sun, 28 Apr 2019, 07:44 Matthias Bläsing, wrote: > > at some point in the past we said, that we wanted to do time based > releases and I would still follow that thinking. > > I would branch any release of master, as late as possible, (not some > random other base), do testing and only minimal cherry-picking, > release. Repeat X months later. > > That way we know: > > - when a release is due > - what will be in the release (the state of master) > +1 to this. At some point in the initial thread on time-based releases Jan also suggested merge windows for master to keep cherry picking minimal. I think being stricter about what gets merged to master and when might be required? I was looking around the NB11 release process a while ago, and wondered about feasibility of making some of those release branch commits be configurable in the master build instead? That way branching could happen more easily later in the schedule, after testing for final beta maybe? Still think next should be NB 12.0 to do time-based releasing properly! As Matthias said, you don't know for sure what's in it until you freeze master, so how do you know it's major or minor? 11.1, 12.1 etc. could be reserved for patch updates where a new full binary download might be warranted? There using release branch possibly makes more sense. Best wishes, Neil >
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Hi, Am Freitag, den 26.04.2019, 22:57 -0700 schrieb Laszlo Kishalmi: > As Gradle was a new out-of-the box feature, I've received some > issues/feedback. I've already fixed some of them. > > I would like to do a release of those changes. Those fixes might be not > that important, but what I'm really curious, that actually can we, and > how can we roll out such a partial patch release? at some point in the past we said, that we wanted to do time based releases and I would still follow that thinking. I would branch any release of master, as late as possible, (not some random other base), do testing and only minimal cherry-picking, release. Repeat X months later. That way we know: - when a release is due - what will be in the release (the state of master) Greetings Matthias - 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
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Well our branching model for release so far is branch, do cherry picks from master if needed, do addition ~14 changes required only for release. It was never palnned to merge back to master. Of course, this strategy is up to the release manager and the community. On 4/27/19 8:08 PM, Wade Chandler wrote: On Sat, Apr 27, 2019, 14:22 Laszlo Kishalmi wrote: On 4/27/19 1:12 AM, Jan Lahoda wrote: Hi Laszlo, On Sat, Apr 27, 2019 at 7:57 AM Laszlo Kishalmi < laszlo.kisha...@gmail.com> wrote: Dear all, As Gradle was a new out-of-the box feature, I've received some issues/feedback. I've already fixed some of them. I would like to do a release of those changes. Those fixes might be not that important, but what I'm really curious, that actually can we, and how can we roll out such a partial patch release? I think it would be awesome if we could do update releases! My plan is the following: 1. Branch the current release into something like: release110-gradle-patch-1 I'd suggest to simply continue with the release110 patch. (The last release is tagged anyway, so we are not loosing that, and in a longer term, it would IMO be easier to simply continue in the release branch with all the changes.) Well right now release110 branch has already some changes which shall go into the 11.1 release (Just a reminder for us, maybe the release branch shall be named to release12x if we plan to have a 12.1 in December) Anyway, I'd keep this effort separated from 11.1, though I guess the new branch would be just merged into the release110 after the Gradle Patch release happens. To me this points to a good reason for the release branches to only live until the release at which point it is fully merged up with master and deleted, then it is tagged. In prep for a dot release, a release branch is created and cleaned up etc; rinse repeat. Then the tags release110 and release111 would be static and not confusing like a release110 with changes after the release. Thanks Wade - 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
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
On Sat, Apr 27, 2019, 14:22 Laszlo Kishalmi wrote: > > On 4/27/19 1:12 AM, Jan Lahoda wrote: > > Hi Laszlo, > > > > On Sat, Apr 27, 2019 at 7:57 AM Laszlo Kishalmi < > laszlo.kisha...@gmail.com> > > wrote: > > > >> Dear all, > >> > >> As Gradle was a new out-of-the box feature, I've received some > >> issues/feedback. I've already fixed some of them. > >> > >> I would like to do a release of those changes. Those fixes might be not > >> that important, but what I'm really curious, that actually can we, and > >> how can we roll out such a partial patch release? > >> > > I think it would be awesome if we could do update releases! > > > > > >> My plan is the following: > >> > >> 1. Branch the current release into something like: > >> release110-gradle-patch-1 > >> > > I'd suggest to simply continue with the release110 patch. (The last > release > > is tagged anyway, so we are not loosing that, and in a longer term, it > > would IMO be easier to simply continue in the release branch with all > the > > changes.) > Well right now release110 branch has already some changes which shall go > into the 11.1 release > > (Just a reminder for us, maybe the release branch shall be named to > release12x if we plan to have a 12.1 in December) > > Anyway, I'd keep this effort separated from 11.1, though I guess the new > branch would be just merged into the release110 after the Gradle Patch > release happens. > To me this points to a good reason for the release branches to only live until the release at which point it is fully merged up with master and deleted, then it is tagged. In prep for a dot release, a release branch is created and cleaned up etc; rinse repeat. Then the tags release110 and release111 would be static and not confusing like a release110 with changes after the release. Thanks Wade
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
On 4/27/19 1:12 AM, Jan Lahoda wrote: Hi Laszlo, On Sat, Apr 27, 2019 at 7:57 AM Laszlo Kishalmi wrote: Dear all, As Gradle was a new out-of-the box feature, I've received some issues/feedback. I've already fixed some of them. I would like to do a release of those changes. Those fixes might be not that important, but what I'm really curious, that actually can we, and how can we roll out such a partial patch release? I think it would be awesome if we could do update releases! My plan is the following: 1. Branch the current release into something like: release110-gradle-patch-1 I'd suggest to simply continue with the release110 patch. (The last release is tagged anyway, so we are not loosing that, and in a longer term, it would IMO be easier to simply continue in the release branch with all the changes.) Well right now release110 branch has already some changes which shall go into the 11.1 release (Just a reminder for us, maybe the release branch shall be named to release12x if we plan to have a 12.1 in December) Anyway, I'd keep this effort separated from 11.1, though I guess the new branch would be just merged into the release110 after the Gradle Patch release happens. 2. Cherry Pick the required changes 3. Increase the patch version (3rd number on the affected modules (I guess only gradle and gradle.java) 4. Set up a jenkins job for that branch to release. 5. The release artifacts would be 1. The new nbm modules from gradle and gradle.java 2. The source artifact would contain those module sources only. 3. I do not know what to put in there exactly: 1. The sources of the two modules keeping the directory structure. so that would be in groovy/gradle and groovy/gradle.java 2. LICENSE and NOTICE files 3. Is there a way to generate the DEPENDENCIES file only for two modules? We should be able to generate the correct LICENSE/NOTICE/DEPENDENCIES without too much problem. We don't currently have an ant target that would allow us to achieve what we want, but we probably should be able to write that. One of the tasks would also be that: a) we need to have the README adjusted to say how to build and use the update; b) possibly we may want a build script to help the user with that. FWIW, I've tried: $ ant -Dclusters.config.update.list=nb.cluster.update -Dnb.cluster.update.dir=update -Dnb.cluster.update=groovy/gradle,groovy/gradle.java -Dcluster.config=update build-source-config It builds something, but I think we can do much better. While that could be a way to go, though I'd rather stick with the current build process and just reduce the output artifacts, but it could be just me feeling that a bit safer choice. 6. Do the PGP signing with my key 7. Start a vote on the artifacts 8. If the vote would be successful: 1. I'd upload the source artifact next to our release 11.0 one. 2. I'd upload the binary nbm-s into the 11.0 distribution UC 3. I do not know how to updates.xml, probably I keep the one generated for the whole NB from step 5 and overwrite the current one. Not sure if we can replace the convenience NBMs and catalog.xml, we may need to place the new NBMs and new catalog.xml into a different directory and update the redirects so that the existing IDEs see the new catalog. in theory it would be an svn commit + a 24h wait time while it is being updated on the mirrors, then we can update it in the netbeans-vm. I'm almost 100% sure that it could work. Jan 9. Again I do not know how much announcement we shall make with this release, maybe a just our announcement list would be enough. Please think it through! Is this feasible, what else shall be done, do I have some misconceptions, etc. ? Also would like to have a peer feedback from our Release Manager Emilian. Thank you! Laszlo Kishalmi - 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
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
On 4/27/19 6:36 AM, Eric Bresie wrote: Hope I’m not misunderstanding here, is what is being discussed There is an applicable ticket (is there one yet for these changes by the way?) associated with the change/defect/enhancement involved Well, there are a handful of fixes, see: https://issues.apache.org/jira/issues/?filter=12346269 Maybe 2-3 other one could join. All these specific to the Gradle integration. There a development branch with the changes being developed The patches are going into the master in form of a PR, then my proposed workflow would be to branch off the current release and then cherry pick from master. Targeted item for eventual 11.0.1 sub release (patch) I would not really name it to 11.0.1 officially. Anyone wanting to try can pull from the branch, and When ready for acceptance then start the process of finalizing the sub release with that (and any additional changes assume an umbrella ticket created and linked to others being targeted ). Or is what is being discussed something more like what I seem to recall in Linux kernel development practices . They would package the main baseline code and then made available the patches with diffs between revisions so the whole code base didn’t have to be provided until it reached the more formal release candidates. Seem to recall they had “release branch” (which was more production version with limited updates) and “development branch” to support development of new updates and features. Yes something like this. Sounds like there are the sub modules and their versions and the aggregate of the overarching Netbeans release. So is the question at what point does the aggregate version get bumped/released give a collection of sub modules updates? Well, there shall be a 11.1 in June if we can make that happen. Can the “patch” just use the normal plugin update mechanism in some way? I seem to recall that being sort of how Eclipse deals with updates but once again maybe I’m misunderstanding the discussion That's the plan. Use the update mechanism already built in and has not really been utilized since we moved to Apache. This would be the first attempt to do a partial-release and that's why I started this thread to collect a community insight on this. Eric Bresie ebre...@gmail.com On April 27, 2019 at 3:12:07 AM CDT, Jan Lahoda wrote: Hi Laszlo, On Sat, Apr 27, 2019 at 7:57 AM Laszlo Kishalmi wrote: Dear all, As Gradle was a new out-of-the box feature, I've received some issues/feedback. I've already fixed some of them. I would like to do a release of those changes. Those fixes might be not that important, but what I'm really curious, that actually can we, and how can we roll out such a partial patch release? I think it would be awesome if we could do update releases! My plan is the following: 1. Branch the current release into something like: release110-gradle-patch-1 I'd suggest to simply continue with the release110 patch. (The last release is tagged anyway, so we are not loosing that, and in a longer term, it would IMO be easier to simply continue in the release branch with all the changes.) 2. Cherry Pick the required changes 3. Increase the patch version (3rd number on the affected modules (I guess only gradle and gradle.java) 4. Set up a jenkins job for that branch to release. 5. The release artifacts would be 1. The new nbm modules from gradle and gradle.java 2. The source artifact would contain those module sources only. 3. I do not know what to put in there exactly: 1. The sources of the two modules keeping the directory structure. so that would be in groovy/gradle and groovy/gradle.java 2. LICENSE and NOTICE files 3. Is there a way to generate the DEPENDENCIES file only for two modules? We should be able to generate the correct LICENSE/NOTICE/DEPENDENCIES without too much problem. We don't currently have an ant target that would allow us to achieve what we want, but we probably should be able to write that. One of the tasks would also be that: a) we need to have the README adjusted to say how to build and use the update; b) possibly we may want a build script to help the user with that. FWIW, I've tried: $ ant -Dclusters.config.update.list=nb.cluster.update -Dnb.cluster.update.dir=update -Dnb.cluster.update=groovy/gradle,groovy/gradle.java -Dcluster.config=update build-source-config It builds something, but I think we can do much better. 6. Do the PGP signing with my key 7. Start a vote on the artifacts 8. If the vote would be successful: 1. I'd upload the source artifact next to our release 11.0 one. 2. I'd upload the binary nbm-s into the 11.0 distribution UC 3. I do not know how to updates.xml, probably I keep the one generated for the whole NB from step 5 and overwrite the current one. Not sure if we can replace the convenience NBMs and catalog.xml, we may need to place the new NBMs and new catalog.xml into a different directory and update the redirects so that the
Re: Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Hope I’m not misunderstanding here, is what is being discussed There is an applicable ticket (is there one yet for these changes by the way?) associated with the change/defect/enhancement involved There a development branch with the changes being developed Targeted item for eventual 11.0.1 sub release (patch) Anyone wanting to try can pull from the branch, and When ready for acceptance then start the process of finalizing the sub release with that (and any additional changes assume an umbrella ticket created and linked to others being targeted ). Or is what is being discussed something more like what I seem to recall in Linux kernel development practices . They would package the main baseline code and then made available the patches with diffs between revisions so the whole code base didn’t have to be provided until it reached the more formal release candidates. Seem to recall they had “release branch” (which was more production version with limited updates) and “development branch” to support development of new updates and features. Sounds like there are the sub modules and their versions and the aggregate of the overarching Netbeans release. So is the question at what point does the aggregate version get bumped/released give a collection of sub modules updates? Can the “patch” just use the normal plugin update mechanism in some way? I seem to recall that being sort of how Eclipse deals with updates but once again maybe I’m misunderstanding the discussion Eric Bresie ebre...@gmail.com > On April 27, 2019 at 3:12:07 AM CDT, Jan Lahoda wrote: > Hi Laszlo, > > On Sat, Apr 27, 2019 at 7:57 AM Laszlo Kishalmi > wrote: > > > Dear all, > > > > As Gradle was a new out-of-the box feature, I've received some > > issues/feedback. I've already fixed some of them. > > > > I would like to do a release of those changes. Those fixes might be not > > that important, but what I'm really curious, that actually can we, and > > how can we roll out such a partial patch release? > > > > I think it would be awesome if we could do update releases! > > > > > > My plan is the following: > > > > 1. Branch the current release into something like: > > release110-gradle-patch-1 > > > > I'd suggest to simply continue with the release110 patch. (The last release > is tagged anyway, so we are not loosing that, and in a longer term, it > would IMO be easier to simply continue in the release branch with all the > changes.) > > 2. Cherry Pick the required changes > > 3. Increase the patch version (3rd number on the affected modules (I > > guess only gradle and gradle.java) > > 4. Set up a jenkins job for that branch to release. > > 5. The release artifacts would be > > 1. The new nbm modules from gradle and gradle.java > > 2. The source artifact would contain those module sources only. > > 3. I do not know what to put in there exactly: > > 1. The sources of the two modules keeping the directory > > structure. so that would be in groovy/gradle and > > groovy/gradle.java > > 2. LICENSE and NOTICE files > > 3. Is there a way to generate the DEPENDENCIES file only for > > two modules? > > > > We should be able to generate the correct LICENSE/NOTICE/DEPENDENCIES > without too much problem. We don't currently have an ant target that would > allow us to achieve what we want, but we probably should be able to write > that. One of the tasks would also be that: a) we need to have the README > adjusted to say how to build and use the update; b) possibly we may want a > build script to help the user with that. > > FWIW, I've tried: > $ ant -Dclusters.config.update.list=nb.cluster.update > -Dnb.cluster.update.dir=update > -Dnb.cluster.update=groovy/gradle,groovy/gradle.java > -Dcluster.config=update build-source-config > > It builds something, but I think we can do much better. > > > > 6. Do the PGP signing with my key > > 7. Start a vote on the artifacts > > 8. If the vote would be successful: > > 1. I'd upload the source artifact next to our release 11.0 one. > > 2. I'd upload the binary nbm-s into the 11.0 distribution UC > > 3. I do not know how to updates.xml, probably I keep the one > > generated for the whole NB from step 5 and overwrite the current > > one. > > > > Not sure if we can replace the convenience NBMs and catalog.xml, we may > need to place the new NBMs and new catalog.xml into a different directory > and update the redirects so that the existing IDEs see the new catalog. > > Jan > > 9. Again I do not know how much announcement we shall make with this > > release, maybe a just our announcement list would be enough. > > > > > Please think it through! Is this feasible, what else shall be done, do I > > have some misconceptions, etc. ? > > > > Also would like to have a peer feedback from our Release Manager Emilian. > > > > Thank you! > > > > Laszlo Kishalmi > > > >
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
On Sat, Apr 27, 2019 at 8:11 AM Enrico Olivelli wrote: > Hi, > IMHO If the changed files are inside the main nb repository you should > release a new version of the whole repository. > To me, it seems wasteful to force the PMC to review >70k files when only a "handful" actually changed, in a handful of modules, just because they happen to be physically located in the same repository as many other modules. > So it would be a 11.0.1 nb, with at least the zip of the sources of the > whole repository. > That fact that users would be able to upgrade the single module is just a > detail. > > For instance in Apache Maven, that is comprised of 100+ independent module, > we have a release of Maven core and every sub module (maven plugin) is > released independently. > But every project has its own repository + sources zip + convenience > binary. > Note that every NetBeans module is also to some degree independent - with some work, we can probably generate a source zip for it, and they have a natural convenience binary format as well. > > I am not suggesting to split NB, I am just saying that you should release > the whole buildable sources bundle and not only a part. > > AFAIK in Apache we are releasing 'source code', and it is important that > who downloads it is able to build it. > I don't think "being able to build" leads to "must have the complete source code for all the modules". A pre-requisite for building might be having the previous full release available, and I don't see a huge issue in that. (If it was only about a build, we could probably build against just the last binary, but for tests, we need some of the full sources which contain tests for other modules.) I think this can be made so that the inconvenience is limited and acceptable. I'd rather invest some energy into improving the infrastructure to make the partial build as convenient as possible than into re-reviewing e.g. PHP support when only Gradle changes. Jan > > Just my 2 cents > > Enrico > > > > Il sab 27 apr 2019, 07:57 Laszlo Kishalmi ha > scritto: > > > Dear all, > > > > As Gradle was a new out-of-the box feature, I've received some > > issues/feedback. I've already fixed some of them. > > > > I would like to do a release of those changes. Those fixes might be not > > that important, but what I'm really curious, that actually can we, and > > how can we roll out such a partial patch release? > > > > My plan is the following: > > > > 1. Branch the current release into something like: > > release110-gradle-patch-1 > > 2. Cherry Pick the required changes > > 3. Increase the patch version (3rd number on the affected modules (I > > guess only gradle and gradle.java) > > 4. Set up a jenkins job for that branch to release. > > 5. The release artifacts would be > > 1. The new nbm modules from gradle and gradle.java > > 2. The source artifact would contain those module sources only. > > 3. I do not know what to put in there exactly: > > 1. The sources of the two modules keeping the directory > > structure. so that would be in groovy/gradle and > > groovy/gradle.java > > 2. LICENSE and NOTICE files > > 3. Is there a way to generate the DEPENDENCIES file only for > > two modules? > > 6. Do the PGP signing with my key > > 7. Start a vote on the artifacts > > 8. If the vote would be successful: > > 1. I'd upload the source artifact next to our release 11.0 one. > > 2. I'd upload the binary nbm-s into the 11.0 distribution UC > > 3. I do not know how to updates.xml, probably I keep the one > > generated for the whole NB from step 5 and overwrite the current > > one. > > 9. Again I do not know how much announcement we shall make with this > > release, maybe a just our announcement list would be enough. > > > > Please think it through! Is this feasible, what else shall be done, do I > > have some misconceptions, etc. ? > > > > Also would like to have a peer feedback from our Release Manager Emilian. > > > > Thank you! > > > > Laszlo Kishalmi > > > > >
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Il giorno sab 27 apr 2019 alle ore 09:02 Laszlo Kishalmi ha scritto: > > Well, I'd avoid changing the version number of the IDE and with that > releasing the complete code-base. I agree. NB is more that one single module. > > The users would be able to build the patch release by downloading the > 11.0 sources and overwrite the files released in the patch, it just > another step in the process and does not make it impossible to build. > > AFAIK Apache releases are just a set of source code. yes, that is was I am trying to say. Enrico > > https://lists.apache.org/thread.html/ccff6dc3152cde4a278a30ef2fdba14c5a1cb54eae56dfcbc9b867ad@%3Cdev.netbeans.apache.org%3E > > On 4/26/19 11:11 PM, Enrico Olivelli wrote: > > Hi, > > IMHO If the changed files are inside the main nb repository you should > > release a new version of the whole repository. > > So it would be a 11.0.1 nb, with at least the zip of the sources of the > > whole repository. > > That fact that users would be able to upgrade the single module is just a > > detail. > > > > For instance in Apache Maven, that is comprised of 100+ independent module, > > we have a release of Maven core and every sub module (maven plugin) is > > released independently. > > But every project has its own repository + sources zip + convenience binary. > > > > I am not suggesting to split NB, I am just saying that you should release > > the whole buildable sources bundle and not only a part. > > > > AFAIK in Apache we are releasing 'source code', and it is important that > > who downloads it is able to build it. > > > > Just my 2 cents > > > > Enrico > > > > > > > > Il sab 27 apr 2019, 07:57 Laszlo Kishalmi ha > > scritto: > > > >> Dear all, > >> > >> As Gradle was a new out-of-the box feature, I've received some > >> issues/feedback. I've already fixed some of them. > >> > >> I would like to do a release of those changes. Those fixes might be not > >> that important, but what I'm really curious, that actually can we, and > >> how can we roll out such a partial patch release? > >> > >> My plan is the following: > >> > >> 1. Branch the current release into something like: > >> release110-gradle-patch-1 > >> 2. Cherry Pick the required changes > >> 3. Increase the patch version (3rd number on the affected modules (I > >> guess only gradle and gradle.java) > >> 4. Set up a jenkins job for that branch to release. > >> 5. The release artifacts would be > >> 1. The new nbm modules from gradle and gradle.java > >> 2. The source artifact would contain those module sources only. > >> 3. I do not know what to put in there exactly: > >> 1. The sources of the two modules keeping the directory > >> structure. so that would be in groovy/gradle and > >> groovy/gradle.java > >> 2. LICENSE and NOTICE files > >> 3. Is there a way to generate the DEPENDENCIES file only for > >> two modules? > >> 6. Do the PGP signing with my key > >> 7. Start a vote on the artifacts > >> 8. If the vote would be successful: > >> 1. I'd upload the source artifact next to our release 11.0 one. > >> 2. I'd upload the binary nbm-s into the 11.0 distribution UC > >> 3. I do not know how to updates.xml, probably I keep the one > >> generated for the whole NB from step 5 and overwrite the current > >> one. > >> 9. Again I do not know how much announcement we shall make with this > >> release, maybe a just our announcement list would be enough. > >> > >> Please think it through! Is this feasible, what else shall be done, do I > >> have some misconceptions, etc. ? > >> > >> Also would like to have a peer feedback from our Release Manager Emilian. > >> > >> Thank you! > >> > >> Laszlo Kishalmi > >> > >> > > - > 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
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Well, I'd avoid changing the version number of the IDE and with that releasing the complete code-base. The users would be able to build the patch release by downloading the 11.0 sources and overwrite the files released in the patch, it just another step in the process and does not make it impossible to build. AFAIK Apache releases are just a set of source code. https://lists.apache.org/thread.html/ccff6dc3152cde4a278a30ef2fdba14c5a1cb54eae56dfcbc9b867ad@%3Cdev.netbeans.apache.org%3E On 4/26/19 11:11 PM, Enrico Olivelli wrote: Hi, IMHO If the changed files are inside the main nb repository you should release a new version of the whole repository. So it would be a 11.0.1 nb, with at least the zip of the sources of the whole repository. That fact that users would be able to upgrade the single module is just a detail. For instance in Apache Maven, that is comprised of 100+ independent module, we have a release of Maven core and every sub module (maven plugin) is released independently. But every project has its own repository + sources zip + convenience binary. I am not suggesting to split NB, I am just saying that you should release the whole buildable sources bundle and not only a part. AFAIK in Apache we are releasing 'source code', and it is important that who downloads it is able to build it. Just my 2 cents Enrico Il sab 27 apr 2019, 07:57 Laszlo Kishalmi ha scritto: Dear all, As Gradle was a new out-of-the box feature, I've received some issues/feedback. I've already fixed some of them. I would like to do a release of those changes. Those fixes might be not that important, but what I'm really curious, that actually can we, and how can we roll out such a partial patch release? My plan is the following: 1. Branch the current release into something like: release110-gradle-patch-1 2. Cherry Pick the required changes 3. Increase the patch version (3rd number on the affected modules (I guess only gradle and gradle.java) 4. Set up a jenkins job for that branch to release. 5. The release artifacts would be 1. The new nbm modules from gradle and gradle.java 2. The source artifact would contain those module sources only. 3. I do not know what to put in there exactly: 1. The sources of the two modules keeping the directory structure. so that would be in groovy/gradle and groovy/gradle.java 2. LICENSE and NOTICE files 3. Is there a way to generate the DEPENDENCIES file only for two modules? 6. Do the PGP signing with my key 7. Start a vote on the artifacts 8. If the vote would be successful: 1. I'd upload the source artifact next to our release 11.0 one. 2. I'd upload the binary nbm-s into the 11.0 distribution UC 3. I do not know how to updates.xml, probably I keep the one generated for the whole NB from step 5 and overwrite the current one. 9. Again I do not know how much announcement we shall make with this release, maybe a just our announcement list would be enough. Please think it through! Is this feasible, what else shall be done, do I have some misconceptions, etc. ? Also would like to have a peer feedback from our Release Manager Emilian. Thank you! Laszlo Kishalmi - 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
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Hi, IMHO If the changed files are inside the main nb repository you should release a new version of the whole repository. So it would be a 11.0.1 nb, with at least the zip of the sources of the whole repository. That fact that users would be able to upgrade the single module is just a detail. For instance in Apache Maven, that is comprised of 100+ independent module, we have a release of Maven core and every sub module (maven plugin) is released independently. But every project has its own repository + sources zip + convenience binary. I am not suggesting to split NB, I am just saying that you should release the whole buildable sources bundle and not only a part. AFAIK in Apache we are releasing 'source code', and it is important that who downloads it is able to build it. Just my 2 cents Enrico Il sab 27 apr 2019, 07:57 Laszlo Kishalmi ha scritto: > Dear all, > > As Gradle was a new out-of-the box feature, I've received some > issues/feedback. I've already fixed some of them. > > I would like to do a release of those changes. Those fixes might be not > that important, but what I'm really curious, that actually can we, and > how can we roll out such a partial patch release? > > My plan is the following: > > 1. Branch the current release into something like: > release110-gradle-patch-1 > 2. Cherry Pick the required changes > 3. Increase the patch version (3rd number on the affected modules (I > guess only gradle and gradle.java) > 4. Set up a jenkins job for that branch to release. > 5. The release artifacts would be > 1. The new nbm modules from gradle and gradle.java > 2. The source artifact would contain those module sources only. > 3. I do not know what to put in there exactly: > 1. The sources of the two modules keeping the directory > structure. so that would be in groovy/gradle and > groovy/gradle.java > 2. LICENSE and NOTICE files > 3. Is there a way to generate the DEPENDENCIES file only for > two modules? > 6. Do the PGP signing with my key > 7. Start a vote on the artifacts > 8. If the vote would be successful: > 1. I'd upload the source artifact next to our release 11.0 one. > 2. I'd upload the binary nbm-s into the 11.0 distribution UC > 3. I do not know how to updates.xml, probably I keep the one > generated for the whole NB from step 5 and overwrite the current > one. > 9. Again I do not know how much announcement we shall make with this > release, maybe a just our announcement list would be enough. > > Please think it through! Is this feasible, what else shall be done, do I > have some misconceptions, etc. ? > > Also would like to have a peer feedback from our Release Manager Emilian. > > Thank you! > > Laszlo Kishalmi > >
