You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Laszlo Kishalmi <la...@gmail.com> on 2019/04/27 05:57:45 UTC
[DISCUSS} Apache NetBeans Gradle Patch 1 Release
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
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Laszlo Kishalmi <la...@gmail.com>.
Well our branching model for release so far is branch, do cherry picks
from master if needed, do addition ~14 changes required only for
release. It was never palnned to merge back to master. Of course, this
strategy is up to the release manager and the community.
On 4/27/19 8:08 PM, Wade Chandler wrote:
> On Sat, Apr 27, 2019, 14:22 Laszlo Kishalmi <la...@gmail.com>
> wrote:
>
>> On 4/27/19 1:12 AM, Jan Lahoda wrote:
>>> Hi Laszlo,
>>>
>>> On Sat, Apr 27, 2019 at 7:57 AM Laszlo Kishalmi <
>> laszlo.kishalmi@gmail.com>
>>> 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.
>>
> To me this points to a good reason for the release branches to only live
> until the release at which point it is fully merged up with master and
> deleted, then it is tagged. In prep for a dot release, a release branch is
> created and cleaned up etc; rinse repeat. Then the tags release110 and
> release111 would be static and not confusing like a release110 with changes
> after the release.
>
> Thanks
>
> Wade
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Wade Chandler <wa...@apache.org>.
On Sat, Apr 27, 2019, 14:22 Laszlo Kishalmi <la...@gmail.com>
wrote:
>
> On 4/27/19 1:12 AM, Jan Lahoda wrote:
> > Hi Laszlo,
> >
> > On Sat, Apr 27, 2019 at 7:57 AM Laszlo Kishalmi <
> laszlo.kishalmi@gmail.com>
> > 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.
>
To me this points to a good reason for the release branches to only live
until the release at which point it is fully merged up with master and
deleted, then it is tagged. In prep for a dot release, a release branch is
created and cleaned up etc; rinse repeat. Then the tags release110 and
release111 would be static and not confusing like a release110 with changes
after the release.
Thanks
Wade
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Laszlo Kishalmi <la...@gmail.com>.
On 4/27/19 1:12 AM, Jan Lahoda wrote:
> Hi Laszlo,
>
> On Sat, Apr 27, 2019 at 7:57 AM Laszlo Kishalmi <la...@gmail.com>
> 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: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Laszlo Kishalmi <la...@gmail.com>.
On 4/27/19 6:36 AM, Eric Bresie wrote:
> 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
Well, there are a handful of fixes, see:
https://issues.apache.org/jira/issues/?filter=12346269
Maybe 2-3 other one could join. All these specific to the Gradle
integration.
>
> There a development branch with the changes being developed
The patches are going into the master in form of a PR, then my proposed
workflow would be to branch off the current release and then cherry
pick from master.
>
> Targeted item for eventual 11.0.1 sub release (patch)
I would not really name it to 11.0.1 officially.
>
> 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.
Yes something like this.
> 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?
Well, there shall be a 11.1 in June if we can make that happen.
>
> 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
That's the plan. Use the update mechanism already built in and has not
really been utilized since we moved to Apache. This would be the first
attempt to do a partial-release and that's why I started this thread to
collect a community insight on this.
>
> Eric Bresie
> Ebresie@gmail.com
>> On April 27, 2019 at 3:12:07 AM CDT, Jan Lahoda <la...@gmail.com> wrote:
>> Hi Laszlo,
>>
>> On Sat, Apr 27, 2019 at 7:57 AM Laszlo Kishalmi <la...@gmail.com>
>> 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
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Eric Bresie <eb...@gmail.com>.
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
Ebresie@gmail.com
> On April 27, 2019 at 3:12:07 AM CDT, Jan Lahoda <la...@gmail.com> wrote:
> Hi Laszlo,
>
> On Sat, Apr 27, 2019 at 7:57 AM Laszlo Kishalmi <la...@gmail.com>
> 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
> >
> >
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Jan Lahoda <la...@gmail.com>.
Hi Laszlo,
On Sat, Apr 27, 2019 at 7:57 AM Laszlo Kishalmi <la...@gmail.com>
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
>
>
Re: Apache Netbeans 11 - Building from Source
Posted by Neil C Smith <ne...@apache.org>.
On Sat, 25 May 2019, 08:55 Tushar Joshi, <tu...@gmail.com> wrote:
>
> I believe that we have to remove this incubator word from this page.
>
AFAIK we keep this because we were still in incubation for NB 11.0?!
Best wishes,
Neil
>
Re: Apache Netbeans 11 - Building from Source
Posted by Tushar Joshi <tu...@gmail.com>.
Hi Antonio,
After going through your points, I agree on keeping that page as it is.
with regards
Tushar
Re: Apache Netbeans 11 - Building from Source
Posted by Antonio <an...@vieiro.net>.
Hi Tushar,
El 25/5/19 a las 9:55, Tushar Joshi escribió:
> Hi Team,
> [...]
>
> Unzip incubating-netbeans-11.0-source.zip
> <https://www.apache.org/dyn/closer.cgi/incubator/netbeans/incubating-netbeans/incubating-11.0/incubating-netbeans-11.0-source.zip>
> in
> a directory of your liking.
> 2.
>
> cd to that directory, and then run ant to build the Apache NetBeans IDE.
> Once built you can run the IDE by typing ./nbbuild/netbeans/bin/netbeans
>
> I believe that we have to remove this incubator word from this page. Where
> should be the new link point for Apache NetBeans 11 sources?
>
AFAIK there's no "netbeans-11.0-source.zip" without the "incubator" part
anywhere in the Apache Mirrors.
Anyway Apache 11.0 was released when NetBeans was still in the Apache
Incubator, so I don't see why the "incubator" prefix has to be removed.
I think that the Apache Incubator Project is one of the greatests
achievements of the ASF. A place where people can learn and grow to
become full fledged Apache TLP projects. I'm grateful to the Apache
Incubator Project for having helped us during the last years.
In my mind having "incubator" in NetBeans 11.0 is a Great Thing,
something to be proud of, and not having it in 12.0 is also a great
thing, a signal we're big enough to break things ourselves!
Kind regards,
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Apache Netbeans 11 - Building from Source
Posted by Tushar Joshi <tu...@gmail.com>.
Hi Team,
On the site at page
https://netbeans.apache.org/download/nb110/nb110.html#_building_from_source
the mirror link for downloading the source ZIP refers to incubator
The wording on this page also contains:
Building from source
To build Apache NetBeans (incubating) 11.0 from source you need:
1.
Oracle’s Java 8 or Open JDK v8.
2.
Apache Ant 1.10 or greater (https://ant.apache.org).
Once you have everything installed then:
1.
Unzip incubating-netbeans-11.0-source.zip
<https://www.apache.org/dyn/closer.cgi/incubator/netbeans/incubating-netbeans/incubating-11.0/incubating-netbeans-11.0-source.zip>
in
a directory of your liking.
2.
cd to that directory, and then run ant to build the Apache NetBeans IDE.
Once built you can run the IDE by typing ./nbbuild/netbeans/bin/netbeans
I believe that we have to remove this incubator word from this page. Where
should be the new link point for Apache NetBeans 11 sources?
with regards
Tushar
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Laszlo Kishalmi <la...@gmail.com>.
Right now it is the actual whole files that have been changed. In
contrast of git patch it does not support file deletions, but as this is
just a patch there is no whole file deletion in there. I've thought that
reviewing simple files is probably simpler, than reviewing an actual patch.
So the build instructions would be something like:
wget http://mirror.metrocast.net/apache/incubator/netbeans/incubating-netbeans/incubating-11.0/incubating-netbeans-11.0-source.zip
wget https://builds.apache.org/job/netbeans-gradle-patch-release/lastSuccessfulBuild/artifact/dist/netbeans-11.0-gradle-patch-1-source.zip
mkdir netbeans -src
unzip incubating-netbeans-11.0-source.zip -d netbeans-src
unzip -o netbeans-11.0-gradle-patch-1-source.zip -d netbeans-src
cd netbeans-src
ant
On 5/13/19 12:42 AM, Geertjan Wielenga wrote:
> Excellent! Can you also describe the optimal way of overwriting the files?
> I.e., is in here an actual patch which we can via a git command incorporate
> into a clone of the main repo?
>
> Gj
>
> On Sun, 12 May 2019 at 19:38, Laszlo Kishalmi <la...@gmail.com>
> wrote:
>
>> Dear all,
>>
>> I was able to assemble something. Please check it and share your
>> thought:
>>
>> https://builds.apache.org/job/netbeans-gradle-patch-release/lastSuccessfulBuild/artifact/dist/netbeans-11.0-gradle-patch-1-source.zip
>>
>> It is not the final one though.
>>
>> In order to build that you need to download the 11.0 sources and
>> overwrite the files from the patch source. The actual patch is a bit
>> more than it normally should as it contains another PR-1206 (
>> https://github.com/apache/netbeans/pull/1206) in order to be able to be
>> buildable with the recent infrastructure changes around netbeans.org.
>>
>> So what's remaining:
>>
>> * Increase the impl versiosns of the changed modules
>> * Extend the build instructions in README.MD
>> * Call for a vote
>> * Update the hosted patches:
>> 1. I'd overwrite the nbms in the release area of 11.0
>> 2. Wait 24 hours for the mirrors to pick up
>> 3. Update the changed sections in update.xml.gz on the netbeans-vm
>> * Send announcement to the netbeans announcement list, as it is just a
>> patch, I do not think we need to announce it on global Apache level,
>> do we?
>>
>>
>> On 4/26/19 10:57 PM, Laszlo Kishalmi 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?
>>>
>>> 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
>>>
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Geertjan Wielenga <ge...@apache.org>.
Excellent! Can you also describe the optimal way of overwriting the files?
I.e., is in here an actual patch which we can via a git command incorporate
into a clone of the main repo?
Gj
On Sun, 12 May 2019 at 19:38, Laszlo Kishalmi <la...@gmail.com>
wrote:
> Dear all,
>
> I was able to assemble something. Please check it and share your
> thought:
>
> https://builds.apache.org/job/netbeans-gradle-patch-release/lastSuccessfulBuild/artifact/dist/netbeans-11.0-gradle-patch-1-source.zip
>
> It is not the final one though.
>
> In order to build that you need to download the 11.0 sources and
> overwrite the files from the patch source. The actual patch is a bit
> more than it normally should as it contains another PR-1206 (
> https://github.com/apache/netbeans/pull/1206) in order to be able to be
> buildable with the recent infrastructure changes around netbeans.org.
>
> So what's remaining:
>
> * Increase the impl versiosns of the changed modules
> * Extend the build instructions in README.MD
> * Call for a vote
> * Update the hosted patches:
> 1. I'd overwrite the nbms in the release area of 11.0
> 2. Wait 24 hours for the mirrors to pick up
> 3. Update the changed sections in update.xml.gz on the netbeans-vm
> * Send announcement to the netbeans announcement list, as it is just a
> patch, I do not think we need to announce it on global Apache level,
> do we?
>
>
> On 4/26/19 10:57 PM, Laszlo Kishalmi 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?
> >
> > 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
> >
>
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Laszlo Kishalmi <la...@gmail.com>.
Dear all,
I was able to assemble something. Please check it and share your
thought:
https://builds.apache.org/job/netbeans-gradle-patch-release/lastSuccessfulBuild/artifact/dist/netbeans-11.0-gradle-patch-1-source.zip
It is not the final one though.
In order to build that you need to download the 11.0 sources and
overwrite the files from the patch source. The actual patch is a bit
more than it normally should as it contains another PR-1206 (
https://github.com/apache/netbeans/pull/1206) in order to be able to be
buildable with the recent infrastructure changes around netbeans.org.
So what's remaining:
* Increase the impl versiosns of the changed modules
* Extend the build instructions in README.MD
* Call for a vote
* Update the hosted patches:
1. I'd overwrite the nbms in the release area of 11.0
2. Wait 24 hours for the mirrors to pick up
3. Update the changed sections in update.xml.gz on the netbeans-vm
* Send announcement to the netbeans announcement list, as it is just a
patch, I do not think we need to announce it on global Apache level,
do we?
On 4/26/19 10:57 PM, Laszlo Kishalmi 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?
>
> 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
>
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Jan Lahoda <la...@gmail.com>.
On Sat, Apr 27, 2019 at 8:11 AM Enrico Olivelli <eo...@gmail.com> 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 <la...@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
> >
> >
>
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Enrico Olivelli <eo...@gmail.com>.
Il giorno sab 27 apr 2019 alle ore 09:02 Laszlo Kishalmi
<la...@gmail.com> ha scritto:
>
> Well, I'd avoid changing the version number of the IDE and with that
> releasing the complete code-base.
I agree. NB is more that one single module.
>
> 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.
yes, that is was I am trying to say.
Enrico
>
> 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 <la...@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Laszlo Kishalmi <la...@gmail.com>.
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 <la...@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Enrico Olivelli <eo...@gmail.com>.
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 <la...@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
>
>
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Antonio <an...@vieiro.net>.
Hi all,
(Regarding the splash screens: I think Laszlo is taking the lead, I just
posted some quick & dirty SVG files as a possible solution).
I agree with Matthias & Laszlo: let's improve the release process even
further before tackling patch releases.
Also let's settle down the repository & jenkins infra changes after the
"-incubator" removal.
Also let's clarify what's in our backlog. Do we want to tackle
plugins.netbeans.org? If so, before release 12? Release 14? When is the
next donation expected?
Cheers,
Antonio
El 28/04/2019 a las 8:44, Matthias Bläsing escribió:
> Hi,
>
> Am Freitag, den 26.04.2019, 22:57 -0700 schrieb Laszlo Kishalmi:
>> 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?
>
> at some point in the past we said, that we wanted to do time based
> releases and I would still follow that thinking.
>
> I would branch any release of master, as late as possible, (not some
> random other base), do testing and only minimal cherry-picking,
> release. Repeat X months later.
>
> That way we know:
>
> - when a release is due
> - what will be in the release (the state of master)
>
> Greetings
>
> Matthias
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Laszlo Kishalmi <la...@gmail.com>.
To be honest, I do not think that would be needed.
There would be no API/SPI changes in the patches, and yes I'm still
talking about Gradle Support specific patch, as I can manage that easily
on my own. So make a dependency on them would probably not worth the
effort. I'm just trying to keep this as simple as I could.
On 4/30/19 1:14 AM, Eric Barboni wrote:
> Hi,
> As a maven fanboy.
>
> Once we vote on a release110_patch I think we can manage a "RELEASE110-PATCH1" release base on the sources of the voted patch ? It will generate every bits but will work I guess.
>
> Regards
> Eric
>
>
> -----Message d'origine-----
> De : Christian Lenz <ch...@gmx.net>
> Envoyé : mardi 30 avril 2019 09:31
> À : dev@netbeans.apache.org
> Objet : AW: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
>
> The stuff from Jaroslav sounds good to me 😊
>
>
> Cheers
>
> Chris
>
>
>
> Von: Laszlo Kishalmi
> Gesendet: Dienstag, 30. April 2019 08:07
> An: dev@netbeans.apache.org
> Betreff: Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
>
>
> On 4/29/19 9:56 PM, Jaroslav Tulach wrote:
>> Hello Laszlo.
>>
>> NetBeans used to be doing "patch releases" in the past. They consist
>> of generating new catalog with NBM files which then automatically
>> appears in the IDEs.
>>
>> That is significantly easier than full release. In the context of Apache, I'd:
>>
>> - create branch release110_patch1 rooted at release110
>> - selectively backported some fixes from master to that branch
>> - whenever a backport is made, update version numbers + dependencies
>> of affected modules only
>>
>> Then we need to vote and release the source ZIP file and upload the
>> NBMs. No need to upload the binary ZIP file itself. IDE update center
>> catalog then needs to point to the new NBMs.
>>
> Yes, that's what I thought to be needed, then people turned this discussion into a general release.
>> Dne neděle 28. dubna 2019 15:47:20 CEST, Laszlo Kishalmi napsal(a):
>>> In order to be able to produce real time based releases our release
>>> process and it's infrastructure have to be improved. Right now the
>>> process consists of ~30 steps out of which ~15 require changes on the
>>> actual code to be released. These includes:
>>>
>>> * New Splash Screens (As you see on the list I'm trying to work on
>>> this as well now)
>> That isn't needed.
>>
>>> * New versions to display in several places
>> That isn't needed either.
>>
>>> * Bumping the versions of the modules on two branches
>> Only bump versions of modules that are affected - only those will be
>> downloaded by Plugin Manager.
>>
>>> * API Signature sealing
>> We can live without this. At least our past experience shows that
>> there are very little API changes in the patch releases anyway.
>>
>> Overall this could be significantly less work than regular release.
>> I'd suggest to start with a branch and a builder that builds source ZIP and NBMs.
>> Then we can start testing the updated modules.
>> -jt
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
RE: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Eric Barboni <sk...@apache.org>.
Hi,
As a maven fanboy.
Once we vote on a release110_patch I think we can manage a "RELEASE110-PATCH1" release base on the sources of the voted patch ? It will generate every bits but will work I guess.
Regards
Eric
-----Message d'origine-----
De : Christian Lenz <ch...@gmx.net>
Envoyé : mardi 30 avril 2019 09:31
À : dev@netbeans.apache.org
Objet : AW: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
The stuff from Jaroslav sounds good to me 😊
Cheers
Chris
Von: Laszlo Kishalmi
Gesendet: Dienstag, 30. April 2019 08:07
An: dev@netbeans.apache.org
Betreff: Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
On 4/29/19 9:56 PM, Jaroslav Tulach wrote:
> Hello Laszlo.
>
> NetBeans used to be doing "patch releases" in the past. They consist
> of generating new catalog with NBM files which then automatically
> appears in the IDEs.
>
> That is significantly easier than full release. In the context of Apache, I'd:
>
> - create branch release110_patch1 rooted at release110
> - selectively backported some fixes from master to that branch
> - whenever a backport is made, update version numbers + dependencies
> of affected modules only
>
> Then we need to vote and release the source ZIP file and upload the
> NBMs. No need to upload the binary ZIP file itself. IDE update center
> catalog then needs to point to the new NBMs.
>
Yes, that's what I thought to be needed, then people turned this discussion into a general release.
> Dne neděle 28. dubna 2019 15:47:20 CEST, Laszlo Kishalmi napsal(a):
>> In order to be able to produce real time based releases our release
>> process and it's infrastructure have to be improved. Right now the
>> process consists of ~30 steps out of which ~15 require changes on the
>> actual code to be released. These includes:
>>
>> * New Splash Screens (As you see on the list I'm trying to work on
>> this as well now)
> That isn't needed.
>
>> * New versions to display in several places
> That isn't needed either.
>
>> * Bumping the versions of the modules on two branches
> Only bump versions of modules that are affected - only those will be
> downloaded by Plugin Manager.
>
>> * API Signature sealing
> We can live without this. At least our past experience shows that
> there are very little API changes in the patch releases anyway.
>
> Overall this could be significantly less work than regular release.
> I'd suggest to start with a branch and a builder that builds source ZIP and NBMs.
> Then we can start testing the updated modules.
> -jt
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
AW: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Christian Lenz <ch...@gmx.net>.
The stuff from Jaroslav sounds good to me 😊
Cheers
Chris
Von: Laszlo Kishalmi
Gesendet: Dienstag, 30. April 2019 08:07
An: dev@netbeans.apache.org
Betreff: Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
On 4/29/19 9:56 PM, Jaroslav Tulach wrote:
> Hello Laszlo.
>
> NetBeans used to be doing "patch releases" in the past. They consist of
> generating new catalog with NBM files which then automatically appears in the
> IDEs.
>
> That is significantly easier than full release. In the context of Apache, I'd:
>
> - create branch release110_patch1 rooted at release110
> - selectively backported some fixes from master to that branch
> - whenever a backport is made, update version numbers + dependencies of
> affected modules only
>
> Then we need to vote and release the source ZIP file and upload the NBMs. No
> need to upload the binary ZIP file itself. IDE update center catalog then
> needs to point to the new NBMs.
>
Yes, that's what I thought to be needed, then people turned this
discussion into a general release.
> Dne neděle 28. dubna 2019 15:47:20 CEST, Laszlo Kishalmi napsal(a):
>> In order to be able to produce real time based releases our release
>> process and it's infrastructure have to be improved. Right now the
>> process consists of ~30 steps out of which ~15 require changes on the
>> actual code to be released. These includes:
>>
>> * New Splash Screens (As you see on the list I'm trying to work on
>> this as well now)
> That isn't needed.
>
>> * New versions to display in several places
> That isn't needed either.
>
>> * Bumping the versions of the modules on two branches
> Only bump versions of modules that are affected - only those will be
> downloaded by Plugin Manager.
>
>> * API Signature sealing
> We can live without this. At least our past experience shows that there are
> very little API changes in the patch releases anyway.
>
> Overall this could be significantly less work than regular release. I'd
> suggest to start with a branch and a builder that builds source ZIP and NBMs.
> Then we can start testing the updated modules.
> -jt
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Laszlo Kishalmi <la...@gmail.com>.
On 4/29/19 9:56 PM, Jaroslav Tulach wrote:
> Hello Laszlo.
>
> NetBeans used to be doing "patch releases" in the past. They consist of
> generating new catalog with NBM files which then automatically appears in the
> IDEs.
>
> That is significantly easier than full release. In the context of Apache, I'd:
>
> - create branch release110_patch1 rooted at release110
> - selectively backported some fixes from master to that branch
> - whenever a backport is made, update version numbers + dependencies of
> affected modules only
>
> Then we need to vote and release the source ZIP file and upload the NBMs. No
> need to upload the binary ZIP file itself. IDE update center catalog then
> needs to point to the new NBMs.
>
Yes, that's what I thought to be needed, then people turned this
discussion into a general release.
> Dne neděle 28. dubna 2019 15:47:20 CEST, Laszlo Kishalmi napsal(a):
>> In order to be able to produce real time based releases our release
>> process and it's infrastructure have to be improved. Right now the
>> process consists of ~30 steps out of which ~15 require changes on the
>> actual code to be released. These includes:
>>
>> * New Splash Screens (As you see on the list I'm trying to work on
>> this as well now)
> That isn't needed.
>
>> * New versions to display in several places
> That isn't needed either.
>
>> * Bumping the versions of the modules on two branches
> Only bump versions of modules that are affected - only those will be
> downloaded by Plugin Manager.
>
>> * API Signature sealing
> We can live without this. At least our past experience shows that there are
> very little API changes in the patch releases anyway.
>
> Overall this could be significantly less work than regular release. I'd
> suggest to start with a branch and a builder that builds source ZIP and NBMs.
> Then we can start testing the updated modules.
> -jt
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Jaroslav Tulach <ja...@gmail.com>.
Hello Laszlo.
NetBeans used to be doing "patch releases" in the past. They consist of
generating new catalog with NBM files which then automatically appears in the
IDEs.
That is significantly easier than full release. In the context of Apache, I'd:
- create branch release110_patch1 rooted at release110
- selectively backported some fixes from master to that branch
- whenever a backport is made, update version numbers + dependencies of
affected modules only
Then we need to vote and release the source ZIP file and upload the NBMs. No
need to upload the binary ZIP file itself. IDE update center catalog then
needs to point to the new NBMs.
Dne neděle 28. dubna 2019 15:47:20 CEST, Laszlo Kishalmi napsal(a):
> In order to be able to produce real time based releases our release
> process and it's infrastructure have to be improved. Right now the
> process consists of ~30 steps out of which ~15 require changes on the
> actual code to be released. These includes:
>
> * New Splash Screens (As you see on the list I'm trying to work on
> this as well now)
That isn't needed.
> * New versions to display in several places
That isn't needed either.
> * Bumping the versions of the modules on two branches
Only bump versions of modules that are affected - only those will be
downloaded by Plugin Manager.
> * API Signature sealing
We can live without this. At least our past experience shows that there are
very little API changes in the patch releases anyway.
Overall this could be significantly less work than regular release. I'd
suggest to start with a branch and a builder that builds source ZIP and NBMs.
Then we can start testing the updated modules.
-jt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Laszlo Kishalmi <la...@gmail.com>.
On 4/28/19 7:01 AM, Matthias Bläsing wrote:
> Hi,
>
> Am Sonntag, den 28.04.2019, 06:47 -0700 schrieb Laszlo Kishalmi:
>> We need to automate these things first (or talk about, if we could skip
>> some of the steps), then we shall be able to discuss time based releases.
>>
> so we invalidate the decission from the past? Sorry, but I think we
> should discuss it some more.
I do not think that we shall invalidate that we would like to do timely
releases. That's doable, however, as I wrote in my 11.0 release
feedback, with the current structure it requires considerable amount of
human resource from the Release Manager.
IMHO we can do 4 releases per year, with the process/setup we have right
now.
It is nothing wrong with the vision of having time based releases by
simply cutting the master branch at a given point of time. It is just we
need to get there somehow.
> I did not follow the release in detail, but do we have a detailed list
> of steps for a release?
Well the Release Steps are documented here for
* 11.0: https://issues.apache.org/jira/browse/NETBEANS-2052
* 10.0: https://issues.apache.org/jira/browse/NETBEANS-1321
> My feeling is, that at least parts are so
> complicated, just because. Antonio for example is already on the
> problem of generating the splash screen.
Yes Antonio is very kind helping with the splash screen, though I still
need to convince NetBeans either the build process or the bootstrap code
to make a good use of that.
>
>
> Many steps will also need to be done for a partitial release, so what
> do we gain from partitial/patch releases?
Well, the number of release steps are much smaller (9, actually 8), as
well as the affected codebase, so it can be rolled out quicker. Maybe a
few hours of work + the VOTING.
>
> Greetings
>
> Matthias
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi,
Am Sonntag, den 28.04.2019, 06:47 -0700 schrieb Laszlo Kishalmi:
>
> We need to automate these things first (or talk about, if we could skip
> some of the steps), then we shall be able to discuss time based releases.
>
so we invalidate the decission from the past? Sorry, but I think we
should discuss it some more.
I did not follow the release in detail, but do we have a detailed list
of steps for a release? My feeling is, that at least parts are so
complicated, just because. Antonio for example is already on the
problem of generating the splash screen.
Many steps will also need to be done for a partitial release, so what
do we gain from partitial/patch releases?
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Eric Bresie <eb...@gmail.com>.
Some of this I believe is already leveraged but just restating in current conversation as applicable.
Seem to recall the “temple” Jira ticket with all the steps define for a release previously.
https://issues.apache.org/jira/browse/NETBEANS-2052 (https://issues.apache.org/jira/browse/NETBEANS-2052?jql=text%20~%20%2211.0%22) is created.
Maybe when a release is initially planned, it needs to be cloned (adding any new sub tasks as changes) and assigned to release manage.
As candidates tickets for inclusion are identified they are linked in the release ticket, marked in the candidate ticket, inclusion of applicable pull requests where applicable.
For patch releases, assume similar clone be created but maybe with a subset of the tasks to reduce work for the full release. What kind of tasks do you think are fully needed in a patch release?
Are there any ways to link a JIRA task with a build requests in some way so that when one or the other is triggered (maybe some state change) it would start a give build to automate some of the tasks? Assume at a minimum some build types may need monitoring to ensure good build quality to an acceptable level. Maybe an extra subtask of “running unit test suite x” with passing at a minimum?
Eric Bresie
Ebresie@gmail.com
> On April 28, 2019 at 8:47:20 AM CDT, Laszlo Kishalmi <la...@gmail.com> wrote:
> Well, I'd put the time based releases aside for a while with the
> following comment on that and stick to the original topic of this
> discussion.
>
> In order to be able to produce real time based releases our release
> process and it's infrastructure have to be improved. Right now the
> process consists of ~30 steps out of which ~15 require changes on the
> actual code to be released. These includes:
>
> * New Splash Screens (As you see on the list I'm trying to work on
> this as well now)
> * New versions to display in several places
> * Bumping the versions of the modules on two branches
> * API Signature sealing
>
> We need to automate these things first (or talk about, if we could skip
> some of the steps), then we shall be able to discuss time based releases.
>
> In theory we shall reach a point when we have a build job in Jenkins
> that input is a git revision and a release version (like 12.0) and it
> would create, a branch with a source and binaries with the correct
> version numbers, branding, etc. and also bump versions on the source branch.
>
> I'd probably itemize the tasks what should be done for this in JIRA and
> create a WIKI page for that as well.
>
> I would just concentrate on releasing a patch with the least but
> sufficient effort right now.
>
>
> On 4/28/19 1:20 AM, Neil C Smith wrote:
> > On Sun, 28 Apr 2019, 07:44 Matthias Bläsing, <mb...@doppel-helix.eu>
> > wrote:
> >
> > > at some point in the past we said, that we wanted to do time based
> > > releases and I would still follow that thinking.
> > >
> > > I would branch any release of master, as late as possible, (not some
> > > random other base), do testing and only minimal cherry-picking,
> > > release. Repeat X months later.
> > >
> > > That way we know:
> > >
> > > - when a release is due
> > > - what will be in the release (the state of master)
> > >
> > +1 to this. At some point in the initial thread on time-based releases Jan
> > also suggested merge windows for master to keep cherry picking minimal. I
> > think being stricter about what gets merged to master and when might be
> > required?
> >
> > I was looking around the NB11 release process a while ago, and wondered
> > about feasibility of making some of those release branch commits be
> > configurable in the master build instead? That way branching could happen
> > more easily later in the schedule, after testing for final beta maybe?
> >
> > Still think next should be NB 12.0 to do time-based releasing properly! As
> > Matthias said, you don't know for sure what's in it until you freeze
> > master, so how do you know it's major or minor?
> >
> > 11.1, 12.1 etc. could be reserved for patch updates where a new full binary
> > download might be warranted? There using release branch possibly makes more
> > sense.
> >
> > Best wishes,
> >
> > Neil
> >
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Laszlo Kishalmi <la...@gmail.com>.
Well, I'd put the time based releases aside for a while with the
following comment on that and stick to the original topic of this
discussion.
In order to be able to produce real time based releases our release
process and it's infrastructure have to be improved. Right now the
process consists of ~30 steps out of which ~15 require changes on the
actual code to be released. These includes:
* New Splash Screens (As you see on the list I'm trying to work on
this as well now)
* New versions to display in several places
* Bumping the versions of the modules on two branches
* API Signature sealing
We need to automate these things first (or talk about, if we could skip
some of the steps), then we shall be able to discuss time based releases.
In theory we shall reach a point when we have a build job in Jenkins
that input is a git revision and a release version (like 12.0) and it
would create, a branch with a source and binaries with the correct
version numbers, branding, etc. and also bump versions on the source branch.
I'd probably itemize the tasks what should be done for this in JIRA and
create a WIKI page for that as well.
I would just concentrate on releasing a patch with the least but
sufficient effort right now.
On 4/28/19 1:20 AM, Neil C Smith wrote:
> On Sun, 28 Apr 2019, 07:44 Matthias Bläsing, <mb...@doppel-helix.eu>
> wrote:
>
>> at some point in the past we said, that we wanted to do time based
>> releases and I would still follow that thinking.
>>
>> I would branch any release of master, as late as possible, (not some
>> random other base), do testing and only minimal cherry-picking,
>> release. Repeat X months later.
>>
>> That way we know:
>>
>> - when a release is due
>> - what will be in the release (the state of master)
>>
> +1 to this. At some point in the initial thread on time-based releases Jan
> also suggested merge windows for master to keep cherry picking minimal. I
> think being stricter about what gets merged to master and when might be
> required?
>
> I was looking around the NB11 release process a while ago, and wondered
> about feasibility of making some of those release branch commits be
> configurable in the master build instead? That way branching could happen
> more easily later in the schedule, after testing for final beta maybe?
>
> Still think next should be NB 12.0 to do time-based releasing properly! As
> Matthias said, you don't know for sure what's in it until you freeze
> master, so how do you know it's major or minor?
>
> 11.1, 12.1 etc. could be reserved for patch updates where a new full binary
> download might be warranted? There using release branch possibly makes more
> sense.
>
> Best wishes,
>
> Neil
>
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Neil C Smith <ne...@apache.org>.
On Sun, 28 Apr 2019, 07:44 Matthias Bläsing, <mb...@doppel-helix.eu>
wrote:
>
> at some point in the past we said, that we wanted to do time based
> releases and I would still follow that thinking.
>
> I would branch any release of master, as late as possible, (not some
> random other base), do testing and only minimal cherry-picking,
> release. Repeat X months later.
>
> That way we know:
>
> - when a release is due
> - what will be in the release (the state of master)
>
+1 to this. At some point in the initial thread on time-based releases Jan
also suggested merge windows for master to keep cherry picking minimal. I
think being stricter about what gets merged to master and when might be
required?
I was looking around the NB11 release process a while ago, and wondered
about feasibility of making some of those release branch commits be
configurable in the master build instead? That way branching could happen
more easily later in the schedule, after testing for final beta maybe?
Still think next should be NB 12.0 to do time-based releasing properly! As
Matthias said, you don't know for sure what's in it until you freeze
master, so how do you know it's major or minor?
11.1, 12.1 etc. could be reserved for patch updates where a new full binary
download might be warranted? There using release branch possibly makes more
sense.
Best wishes,
Neil
>
Re: [DISCUSS} Apache NetBeans Gradle Patch 1 Release
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi,
Am Freitag, den 26.04.2019, 22:57 -0700 schrieb Laszlo Kishalmi:
> 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?
at some point in the past we said, that we wanted to do time based
releases and I would still follow that thinking.
I would branch any release of master, as late as possible, (not some
random other base), do testing and only minimal cherry-picking,
release. Repeat X months later.
That way we know:
- when a release is due
- what will be in the release (the state of master)
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists