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 <laszlo.kisha...@gmail.com> 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 > > >
