On Sat, Apr 27, 2019 at 8:11 AM Enrico Olivelli <[email protected]> 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 <[email protected]> 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 > > > > >
