Well, I'd avoid changing the version number of the IDE and with that
releasing the complete code-base.
The users would be able to build the patch release by downloading the
11.0 sources and overwrite the files released in the patch, it just
another step in the process and does not make it impossible to build.
AFAIK Apache releases are just a set of source code.
https://lists.apache.org/thread.html/ccff6dc3152cde4a278a30ef2fdba14c5a1cb54eae56dfcbc9b867ad@%3Cdev.netbeans.apache.org%3E
On 4/26/19 11:11 PM, Enrico Olivelli wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
