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