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 [email protected] > On April 27, 2019 at 3:12:07 AM CDT, Jan Lahoda <[email protected]> wrote: > Hi Laszlo, > > On Sat, Apr 27, 2019 at 7:57 AM Laszlo Kishalmi <[email protected]> > 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 > > > >
