On 4/27/19 1:12 AM, Jan Lahoda 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.)
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: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
