Re: Time to branch for the release candidate?

[Emilian Bold]

>  I think we should be able to release from master without branching.

Having release branches is quite useful if only because we can do per-release 
fixes while master/ has diverged / refactored that whole area.

--emi

‐‐‐ Original Message ‐‐‐

On 26 April 2018 5:08 PM, Wade Chandler  wrote:

> +1 and even if we don’t have a “dev” branch, I think we should be able to 
> release from master without branching. We should be working to stabilize 
> things near a release, and perhaps we ask folks not to merge new features to 
> master, but only fixes for a period of time. If we could support feature 
> flags, then even better, and for new modules and such I think we can through 
> configuration and clusters, to not have them enabled and included by default, 
> but not with big new features to existing modules. We would need new switches 
> in the config file for those. Then new work can be enabled or disabled for a 
> release depending on how far along it is.
> 
> Either way, I feel master should always build, run, and be as stable as 
> possible. Now, in this interim phase where we are still trying to get over to 
> Apache all that is NB, it may be harder or nearly impossible since it is so 
> much to bring over, but I think that should be our goal going forward once 
> the “drop” has happened.
> 
> My $0.02,
> 
> Wade
> 
> 
> 
> 
> Wade Chandler
> 
> e: cons...@wadechandler.com
> 
> t: @wadechandler
> 
> https://www.linkedin.com/in/wade-chandler
> 
> > On Apr 17, 2018, at 10:09 AM, Christian Lenz christian.l...@gmx.net wrote:
> > 
> > Master shouldn’t be that one, where the wild development is going on. 
> > Master should be that one which is already live.
> > 
> > In General, what gitflow does. Wild development is going on on the dev 
> > branch, for the next release. If whatever is finished, there is a release 
> > branch. After that, it will merged into master and created a tag.
> > 
> > If this is not possible, then an other solution is that develop stays clean 
> > and always releasable. You only work on Feature branches. After the Feature 
> > is finished and ready to go, it will merged into develop. Someday you can 
> > create a release branch of develop.
> 
> --
> 
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> 
> For additional commands, e-mail: dev-h...@netbeans.incubator.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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Time to branch for the release candidate?

[John McDonnell]

@Laszlo, Have you made it public?

It's not loading for me, even when I'm logged in.


Regards


John

On 27 April 2018 at 04:20, Laszlo Kishalmi 
wrote:

> Well, I've got the rights to share my dashboard.
>
> It's called: NetBeans Overview
>
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12332552
>
>
> On 04/26/2018 03:53 PM, Laszlo Kishalmi wrote:
>
>> I went though the open issues with PR-s list.
>>
>> I've marked 17 issues resolved due to it's PR merged, and added some
>> flags for 9.0 as well.
>>
>> Right now in JIRA we have 27 open issues with PR and 9 of them are marked
>> for 9.0 release.
>>
>> We still have 31 open PRs.
>>
>> As of 9.0: We have 40 issues open (I've marked the 3 blocker ones, that
>> pointed out by Geertjan)
>>
>> 3 blocker
>>
>> 6 critical
>>
>> 25 major
>>
>> 5 minor
>>
>> 1 trivial
>>
>> 9 of these has PR-s
>>
>>
>> Just one note: Our most voted/watched issue is supporting JUnit 5
>>
>>
>> On 04/26/2018 10:56 AM, Laszlo Kishalmi wrote:
>>
>>> Well,
>>>
>>> I'm trying to collect the remaining things to do for 9.0 release for a
>>> week now, from GitHub PR-s, JIRA and this mailing list. Regarding 9.0 in
>>> numbers are the following (none may be accurate, though):
>>>
>>> We have 31 open PR-s in GitHub (not necessary 9.0 related)
>>>
>>> We have 44 open issues with PR-s.
>>>
>>> We have 32 open issues marked for 9.0
>>>
>>> We also have 5 open issues with PR-s for 9.0
>>>
>>> The issues and PRs are not really aligned.
>>>
>>> Well this does not necessarily means that we should not branch for
>>> release. I just would like to say, we probably need to be more focused on
>>> what we are doing.
>>>
>>> I could promise to go over the open issues and the PR-s and close those
>>> which have merged PRs-.
>>>
>>> Also I feel the number of open PRs is quite high, though it might really
>>> mean that changes that we do not want to include into 9.0 are piling up
>>> (indicates the need of the release branch).
>>>
>>> Also those 5 issues with PR-s might just go into master in the following
>>> days and we could make the release branch after that.
>>>
>>> So If I would vote for release branch now it would be 0/-1 right now as
>>> we (or maybe just me) can't really see clearly on 9.0.
>>>
>>>
>>>
>>> On 04/17/2018 05:52 AM, Neil C Smith wrote:
>>>
 On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach 
 wrote:

 Yeah, there are changes in the queue for the master branch that could be
> too destabilizing. To avoid something like that to negatively
> influence the
> 9.0 release, I'd suggest to create a branch release/9.0 and put only
> the
> safe fixes ready for 9.0 there. The wild development would continue in
> the
> master branch.
>
> +1 to branching and that.  Longer term perhaps a more gitflow-like
 system
 where PR's come into a develop branch too?

   A question, though - I assume this will branch off master now, not
 from
 the beta tag?  Given that in NetCAT we were testing the beta, I assume
 there is nothing you'd consider "too destabilizing"  between then and
 now?

 Best wishes,

 Neil

>>>
>>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Time to branch for the release candidate?

[Laszlo Kishalmi]

Well, I've got the rights to share my dashboard.

It's called: NetBeans Overview

https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12332552

On 04/26/2018 03:53 PM, Laszlo Kishalmi wrote:

I went though the open issues with PR-s list.

I've marked 17 issues resolved due to it's PR merged, and added some 
flags for 9.0 as well.


Right now in JIRA we have 27 open issues with PR and 9 of them are 
marked for 9.0 release.


We still have 31 open PRs.

As of 9.0: We have 40 issues open (I've marked the 3 blocker ones, 
that pointed out by Geertjan)


3 blocker

6 critical

25 major

5 minor

1 trivial

9 of these has PR-s


Just one note: Our most voted/watched issue is supporting JUnit 5


On 04/26/2018 10:56 AM, Laszlo Kishalmi wrote:

Well,

I'm trying to collect the remaining things to do for 9.0 release for 
a week now, from GitHub PR-s, JIRA and this mailing list. Regarding 
9.0 in numbers are the following (none may be accurate, though):


We have 31 open PR-s in GitHub (not necessary 9.0 related)

We have 44 open issues with PR-s.

We have 32 open issues marked for 9.0

We also have 5 open issues with PR-s for 9.0

The issues and PRs are not really aligned.

Well this does not necessarily means that we should not branch for 
release. I just would like to say, we probably need to be more 
focused on what we are doing.


I could promise to go over the open issues and the PR-s and close 
those which have merged PRs-.


Also I feel the number of open PRs is quite high, though it might 
really mean that changes that we do not want to include into 9.0 are 
piling up (indicates the need of the release branch).


Also those 5 issues with PR-s might just go into master in the 
following days and we could make the release branch after that.


So If I would vote for release branch now it would be 0/-1 right now 
as we (or maybe just me) can't really see clearly on 9.0.




On 04/17/2018 05:52 AM, Neil C Smith wrote:
On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach 


wrote:

Yeah, there are changes in the queue for the master branch that 
could be
too destabilizing. To avoid something like that to negatively 
influence the
9.0 release, I'd suggest to create a branch release/9.0 and put 
only the
safe fixes ready for 9.0 there. The wild development would continue 
in the

master branch.

+1 to branching and that.  Longer term perhaps a more gitflow-like 
system

where PR's come into a develop branch too?

  A question, though - I assume this will branch off master now, not 
from

the beta tag?  Given that in NetCAT we were testing the beta, I assume
there is nothing you'd consider "too destabilizing"  between then 
and now?


Best wishes,

Neil







-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Time to branch for the release candidate?

[Eirik Bakke]

Here's a bug, with a pull request and some discussion, that's not quite a 
blocker (it existed in 8.2) but still arguably critical:

https://issues.apache.org/jira/browse/NETBEANS-403
"Pressing Home/End scrolls to beginning/end of whole document if tooltip is 
open"

There's an ongoing discussion on 
https://github.com/apache/incubator-netbeans/pull/507 .

-- Eirik


On 4/26/18, 6:53 PM, "Laszlo Kishalmi" 
> wrote:

I went though the open issues with PR-s list.

I've marked 17 issues resolved due to it's PR merged, and added some
flags for 9.0 as well.

Right now in JIRA we have 27 open issues with PR and 9 of them are
marked for 9.0 release.

We still have 31 open PRs.

As of 9.0: We have 40 issues open (I've marked the 3 blocker ones, that
pointed out by Geertjan)

3 blocker

6 critical

25 major

5 minor

1 trivial

9 of these has PR-s


Just one note: Our most voted/watched issue is supporting JUnit 5


On 04/26/2018 10:56 AM, Laszlo Kishalmi wrote:
Well,

I'm trying to collect the remaining things to do for 9.0 release for a
week now, from GitHub PR-s, JIRA and this mailing list. Regarding 9.0
in numbers are the following (none may be accurate, though):

We have 31 open PR-s in GitHub (not necessary 9.0 related)

We have 44 open issues with PR-s.

We have 32 open issues marked for 9.0

We also have 5 open issues with PR-s for 9.0

The issues and PRs are not really aligned.

Well this does not necessarily means that we should not branch for
release. I just would like to say, we probably need to be more focused
on what we are doing.

I could promise to go over the open issues and the PR-s and close
those which have merged PRs-.

Also I feel the number of open PRs is quite high, though it might
really mean that changes that we do not want to include into 9.0 are
piling up (indicates the need of the release branch).

Also those 5 issues with PR-s might just go into master in the
following days and we could make the release branch after that.

So If I would vote for release branch now it would be 0/-1 right now
as we (or maybe just me) can't really see clearly on 9.0.



On 04/17/2018 05:52 AM, Neil C Smith wrote:
On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach 
>
wrote:

Yeah, there are changes in the queue for the master branch that
could be
too destabilizing. To avoid something like that to negatively
influence the
9.0 release, I'd suggest to create a branch release/9.0 and put only
the
safe fixes ready for 9.0 there. The wild development would continue
in the
master branch.

+1 to branching and that.  Longer term perhaps a more gitflow-like
system
where PR's come into a develop branch too?

  A question, though - I assume this will branch off master now, not
from
the beta tag?  Given that in NetCAT we were testing the beta, I assume
there is nothing you'd consider "too destabilizing"  between then and
now?

Best wishes,

Neil



-
To unsubscribe, e-mail: 
dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: 
dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Time to branch for the release candidate?

[Laszlo Kishalmi]

I went though the open issues with PR-s list.

I've marked 17 issues resolved due to it's PR merged, and added some 
flags for 9.0 as well.


Right now in JIRA we have 27 open issues with PR and 9 of them are 
marked for 9.0 release.


We still have 31 open PRs.

As of 9.0: We have 40 issues open (I've marked the 3 blocker ones, that 
pointed out by Geertjan)


3 blocker

6 critical

25 major

5 minor

1 trivial

9 of these has PR-s


Just one note: Our most voted/watched issue is supporting JUnit 5


On 04/26/2018 10:56 AM, Laszlo Kishalmi wrote:

Well,

I'm trying to collect the remaining things to do for 9.0 release for a 
week now, from GitHub PR-s, JIRA and this mailing list. Regarding 9.0 
in numbers are the following (none may be accurate, though):


We have 31 open PR-s in GitHub (not necessary 9.0 related)

We have 44 open issues with PR-s.

We have 32 open issues marked for 9.0

We also have 5 open issues with PR-s for 9.0

The issues and PRs are not really aligned.

Well this does not necessarily means that we should not branch for 
release. I just would like to say, we probably need to be more focused 
on what we are doing.


I could promise to go over the open issues and the PR-s and close 
those which have merged PRs-.


Also I feel the number of open PRs is quite high, though it might 
really mean that changes that we do not want to include into 9.0 are 
piling up (indicates the need of the release branch).


Also those 5 issues with PR-s might just go into master in the 
following days and we could make the release branch after that.


So If I would vote for release branch now it would be 0/-1 right now 
as we (or maybe just me) can't really see clearly on 9.0.




On 04/17/2018 05:52 AM, Neil C Smith wrote:

On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach 
wrote:

Yeah, there are changes in the queue for the master branch that 
could be
too destabilizing. To avoid something like that to negatively 
influence the
9.0 release, I'd suggest to create a branch release/9.0 and put only 
the
safe fixes ready for 9.0 there. The wild development would continue 
in the

master branch.

+1 to branching and that.  Longer term perhaps a more gitflow-like 
system

where PR's come into a develop branch too?

  A question, though - I assume this will branch off master now, not 
from

the beta tag?  Given that in NetCAT we were testing the beta, I assume
there is nothing you'd consider "too destabilizing"  between then and 
now?


Best wishes,

Neil





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Time to branch for the release candidate?

[Geertjan Wielenga]

On Thu, Apr 26, 2018 at 7:56 PM, Laszlo Kishalmi 
wrote:

> Well,
>
> I'm trying to collect the remaining things to do for 9.0 release



There are 3 blockers:

https://issues.apache.org/jira/issues/?filter=12343308

Thanks,

Gj





> for a week now, from GitHub PR-s, JIRA and this mailing list. Regarding
> 9.0 in numbers are the following (none may be accurate, though):
>
> We have 31 open PR-s in GitHub (not necessary 9.0 related)
>
> We have 44 open issues with PR-s.
>
> We have 32 open issues marked for 9.0
>
> We also have 5 open issues with PR-s for 9.0
>
> The issues and PRs are not really aligned.
>
> Well this does not necessarily means that we should not branch for
> release. I just would like to say, we probably need to be more focused on
> what we are doing.
>
> I could promise to go over the open issues and the PR-s and close those
> which have merged PRs-.
>
> Also I feel the number of open PRs is quite high, though it might really
> mean that changes that we do not want to include into 9.0 are piling up
> (indicates the need of the release branch).
>
> Also those 5 issues with PR-s might just go into master in the following
> days and we could make the release branch after that.
>
> So If I would vote for release branch now it would be 0/-1 right now as we
> (or maybe just me) can't really see clearly on 9.0.
>
>
>
> On 04/17/2018 05:52 AM, Neil C Smith wrote:
>
>> On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach 
>> wrote:
>>
>> Yeah, there are changes in the queue for the master branch that could be
>>> too destabilizing. To avoid something like that to negatively influence
>>> the
>>> 9.0 release, I'd suggest to create a branch release/9.0 and put only the
>>> safe fixes ready for 9.0 there. The wild development would continue in
>>> the
>>> master branch.
>>>
>>> +1 to branching and that.  Longer term perhaps a more gitflow-like system
>> where PR's come into a develop branch too?
>>
>>   A question, though - I assume this will branch off master now, not from
>> the beta tag?  Given that in NetCAT we were testing the beta, I assume
>> there is nothing you'd consider "too destabilizing"  between then and now?
>>
>> Best wishes,
>>
>> Neil
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Time to branch for the release candidate?

[Geertjan Wielenga]

On Thu, Apr 26, 2018 at 8:26 PM, Peter Steele  wrote:

> Just for my interest, which types of people can approve Pull Requests?



NetBeans is simply an Apache project, in the Apache incubator. Nothing that
we're doing here is specific to NetBeans, everything is the same as at
Apache Maven, Apache Groovy, and hundreds at least of other projects.

E.g., to answer your question, there are very clear guidelines:

https://www.apache.org/dev/new-committers-guide.html

Thanks,

Gj




> As
> we are now open source the community is deciding what's important by
> providing the PR's but we have quite a few stacked up. It has previously
> been mentioned in someone else request to get one approved that they should
> just sent a message to dev but that's not really a process, it's just
> hiding the fact there isn't really one.
>
> Also who gets to flag an issue as 9.0, I guess in general what makes an
> issue relevant to a particular version or not.
>
> As we move to integrating the next code donation, there will now be two
> parallel streams running. Bug fixing/enhancing the current code base and
> integrating the new modules. What is the strategy here, branching seems
> like best approach here but it looks like aren't doing this. What is the
> plan to effectively manage the two streams?
>
> On Thu, 26 Apr 2018, 18:56 Laszlo Kishalmi, 
> wrote:
>
> > Well,
> >
> > I'm trying to collect the remaining things to do for 9.0 release for a
> > week now, from GitHub PR-s, JIRA and this mailing list. Regarding 9.0 in
> > numbers are the following (none may be accurate, though):
> >
> > We have 31 open PR-s in GitHub (not necessary 9.0 related)
> >
> > We have 44 open issues with PR-s.
> >
> > We have 32 open issues marked for 9.0
> >
> > We also have 5 open issues with PR-s for 9.0
> >
> > The issues and PRs are not really aligned.
> >
> > Well this does not necessarily means that we should not branch for
> > release. I just would like to say, we probably need to be more focused
> > on what we are doing.
> >
> > I could promise to go over the open issues and the PR-s and close those
> > which have merged PRs-.
> >
> > Also I feel the number of open PRs is quite high, though it might really
> > mean that changes that we do not want to include into 9.0 are piling up
> > (indicates the need of the release branch).
> >
> > Also those 5 issues with PR-s might just go into master in the following
> > days and we could make the release branch after that.
> >
> > So If I would vote for release branch now it would be 0/-1 right now as
> > we (or maybe just me) can't really see clearly on 9.0.
> >
> >
> >
> > On 04/17/2018 05:52 AM, Neil C Smith wrote:
> > > On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach <
> jaroslav.tul...@gmail.com>
> > > wrote:
> > >
> > >> Yeah, there are changes in the queue for the master branch that could
> be
> > >> too destabilizing. To avoid something like that to negatively
> influence
> > the
> > >> 9.0 release, I'd suggest to create a branch release/9.0 and put only
> the
> > >> safe fixes ready for 9.0 there. The wild development would continue in
> > the
> > >> master branch.
> > >>
> > > +1 to branching and that.  Longer term perhaps a more gitflow-like
> system
> > > where PR's come into a develop branch too?
> > >
> > >   A question, though - I assume this will branch off master now, not
> from
> > > the beta tag?  Given that in NetCAT we were testing the beta, I assume
> > > there is nothing you'd consider "too destabilizing"  between then and
> > now?
> > >
> > > Best wishes,
> > >
> > > Neil
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>

Re: Time to branch for the release candidate?

[Peter Steele]

Just for my interest, which types of people can approve Pull Requests? As
we are now open source the community is deciding what's important by
providing the PR's but we have quite a few stacked up. It has previously
been mentioned in someone else request to get one approved that they should
just sent a message to dev but that's not really a process, it's just
hiding the fact there isn't really one.

Also who gets to flag an issue as 9.0, I guess in general what makes an
issue relevant to a particular version or not.

As we move to integrating the next code donation, there will now be two
parallel streams running. Bug fixing/enhancing the current code base and
integrating the new modules. What is the strategy here, branching seems
like best approach here but it looks like aren't doing this. What is the
plan to effectively manage the two streams?

On Thu, 26 Apr 2018, 18:56 Laszlo Kishalmi, 
wrote:

> Well,
>
> I'm trying to collect the remaining things to do for 9.0 release for a
> week now, from GitHub PR-s, JIRA and this mailing list. Regarding 9.0 in
> numbers are the following (none may be accurate, though):
>
> We have 31 open PR-s in GitHub (not necessary 9.0 related)
>
> We have 44 open issues with PR-s.
>
> We have 32 open issues marked for 9.0
>
> We also have 5 open issues with PR-s for 9.0
>
> The issues and PRs are not really aligned.
>
> Well this does not necessarily means that we should not branch for
> release. I just would like to say, we probably need to be more focused
> on what we are doing.
>
> I could promise to go over the open issues and the PR-s and close those
> which have merged PRs-.
>
> Also I feel the number of open PRs is quite high, though it might really
> mean that changes that we do not want to include into 9.0 are piling up
> (indicates the need of the release branch).
>
> Also those 5 issues with PR-s might just go into master in the following
> days and we could make the release branch after that.
>
> So If I would vote for release branch now it would be 0/-1 right now as
> we (or maybe just me) can't really see clearly on 9.0.
>
>
>
> On 04/17/2018 05:52 AM, Neil C Smith wrote:
> > On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach 
> > wrote:
> >
> >> Yeah, there are changes in the queue for the master branch that could be
> >> too destabilizing. To avoid something like that to negatively influence
> the
> >> 9.0 release, I'd suggest to create a branch release/9.0 and put only the
> >> safe fixes ready for 9.0 there. The wild development would continue in
> the
> >> master branch.
> >>
> > +1 to branching and that.  Longer term perhaps a more gitflow-like system
> > where PR's come into a develop branch too?
> >
> >   A question, though - I assume this will branch off master now, not from
> > the beta tag?  Given that in NetCAT we were testing the beta, I assume
> > there is nothing you'd consider "too destabilizing"  between then and
> now?
> >
> > Best wishes,
> >
> > Neil
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Time to branch for the release candidate?

[Laszlo Kishalmi]

Well,

I'm trying to collect the remaining things to do for 9.0 release for a 
week now, from GitHub PR-s, JIRA and this mailing list. Regarding 9.0 in 
numbers are the following (none may be accurate, though):


We have 31 open PR-s in GitHub (not necessary 9.0 related)

We have 44 open issues with PR-s.

We have 32 open issues marked for 9.0

We also have 5 open issues with PR-s for 9.0

The issues and PRs are not really aligned.

Well this does not necessarily means that we should not branch for 
release. I just would like to say, we probably need to be more focused 
on what we are doing.


I could promise to go over the open issues and the PR-s and close those 
which have merged PRs-.


Also I feel the number of open PRs is quite high, though it might really 
mean that changes that we do not want to include into 9.0 are piling up 
(indicates the need of the release branch).


Also those 5 issues with PR-s might just go into master in the following 
days and we could make the release branch after that.


So If I would vote for release branch now it would be 0/-1 right now as 
we (or maybe just me) can't really see clearly on 9.0.




On 04/17/2018 05:52 AM, Neil C Smith wrote:

On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach 
wrote:


Yeah, there are changes in the queue for the master branch that could be
too destabilizing. To avoid something like that to negatively influence the
9.0 release, I'd suggest to create a branch release/9.0 and put only the
safe fixes ready for 9.0 there. The wild development would continue in the
master branch.


+1 to branching and that.  Longer term perhaps a more gitflow-like system
where PR's come into a develop branch too?

  A question, though - I assume this will branch off master now, not from
the beta tag?  Given that in NetCAT we were testing the beta, I assume
there is nothing you'd consider "too destabilizing"  between then and now?

Best wishes,

Neil



-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Time to branch for the release candidate?

[Jan Lahoda]

I think a release branch serves several purposes, among others:
-ability to add changes that are specific for the release (in case of
NetBeans things like: release branding, updating module spec. versions to
release format, disabling exceptions, etc.)
-let development (features and general bugfixing) continue even during the
late pre-release stages. This may include:
--allowing bugfixes that are not crucial, or simply too dangerous, for the
release
--allowing (shared) development during the final stages of the release (in
our current situation, this may take quite some time: voting for a release
cadidate takes roughly a week (3 days here, 3 days on the incubator), so if
the release votes fail a few times, the final stages can easily span
several weeks)
-ability to release update release for several past major releases (not
that this would be used much in NetBeans in the past)

I think feature branches are good to develop a (biggish) feature, but when
it is (almost) ready, it needs to be part of some kind of a shared branch,
otherwise people won't (be able to) test and use it.

I agree that the mainline should work as best as it can (and I am myself
running a bleeding edge NetBeans on a bleeding edge JDK), but I think this
is for folks that don't mind (too much) reverting to their last good build
if the new one does not work good enough (which inevitably happens from
time to time, when using bleeding edge).

Jan


On Thu, Apr 26, 2018 at 4:08 PM, Wade Chandler 
wrote:

> +1 and even if we don’t have a “dev” branch, I think we should be able to
> release from master without branching. We should be working to stabilize
> things near a release, and perhaps we ask folks not to merge new features
> to master, but only fixes for a period of time. If we could support feature
> flags, then even better, and for new modules and such I think we can
> through configuration and clusters, to not have them enabled and included
> by default, but not with big new features to existing modules. We would
> need new switches in the config file for those. Then new work can be
> enabled or disabled for a release depending on how far along it is.
>
> Either way, I feel master should always build, run, and be as stable as
> possible. Now, in this interim phase where we are still trying to get over
> to Apache all that is NB, it may be harder or nearly impossible since it is
> so much to bring over, but I think that should be our goal going forward
> once the “drop” has happened.
>
> My $0.02,
>
> Wade
>
>
> ===
>
> Wade Chandler
> e: cons...@wadechandler.com
> t: @wadechandler
> https://www.linkedin.com/in/wade-chandler
>
>
> > On Apr 17, 2018, at 10:09 AM, Christian Lenz 
> wrote:
> >
> > Master shouldn’t be that one, where the wild development is going on.
> Master should be that one which is already live.
> > In General, what gitflow does. Wild development is going on on the dev
> branch, for the next release. If whatever is finished, there is a release
> branch. After that, it will merged into master and created a tag.
> >
> > If this is not possible, then an other solution is that develop stays
> clean and always releasable. You only work on Feature branches. After the
> Feature is finished and ready to go, it will merged into develop. Someday
> you can create a release branch of develop.
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Time to branch for the release candidate?

[Wade Chandler]

+1 and even if we don’t have a “dev” branch, I think we should be able to 
release from master without branching. We should be working to stabilize things 
near a release, and perhaps we ask folks not to merge new features to master, 
but only fixes for a period of time. If we could support feature flags, then 
even better, and for new modules and such I think we can through configuration 
and clusters, to not have them enabled and included by default, but not with 
big new features to existing modules. We would need new switches in the config 
file for those. Then new work can be enabled or disabled for a release 
depending on how far along it is.

Either way, I feel master should always build, run, and be as stable as 
possible. Now, in this interim phase where we are still trying to get over to 
Apache all that is NB, it may be harder or nearly impossible since it is so 
much to bring over, but I think that should be our goal going forward once the 
“drop” has happened.

My $0.02,

Wade


===

Wade Chandler
e: cons...@wadechandler.com
t: @wadechandler
https://www.linkedin.com/in/wade-chandler


> On Apr 17, 2018, at 10:09 AM, Christian Lenz  wrote:
> 
> Master shouldn’t be that one, where the wild development is going on. Master 
> should be that one which is already live.
> In General, what gitflow does. Wild development is going on on the dev 
> branch, for the next release. If whatever is finished, there is a release 
> branch. After that, it will merged into master and created a tag.
> 
> If this is not possible, then an other solution is that develop stays clean 
> and always releasable. You only work on Feature branches. After the Feature 
> is finished and ready to go, it will merged into develop. Someday you can 
> create a release branch of develop.
> 


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Time to branch for the release candidate?

[Peter Steele]

+1 to Chris / Neil

You shouldn't be developing in master, ideally

On Tue, 17 Apr 2018, 15:10 Christian Lenz, <christian.l...@gmx.net> wrote:

> Master shouldn’t be that one, where the wild development is going on.
> Master should be that one which is already live.
> In General, what gitflow does. Wild development is going on on the dev
> branch, for the next release. If whatever is finished, there is a release
> branch. After that, it will merged into master and created a tag.
>
> If this is not possible, then an other solution is that develop stays
> clean and always releasable. You only work on Feature branches. After the
> Feature is finished and ready to go, it will merged into develop. Someday
> you can create a release branch of develop.
>
>
> Cheer
>
> Chris
>
> Von: Neil C Smith
> Gesendet: Dienstag, 17. April 2018 14:53
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Time to branch for the release candidate?
>
> On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach <jaroslav.tul...@gmail.com>
> wrote:
>
> > Yeah, there are changes in the queue for the master branch that could be
> > too destabilizing. To avoid something like that to negatively influence
> the
> > 9.0 release, I'd suggest to create a branch release/9.0 and put only the
> > safe fixes ready for 9.0 there. The wild development would continue in
> the
> > master branch.
> >
>
> +1 to branching and that.  Longer term perhaps a more gitflow-like system
> where PR's come into a develop branch too?
>
>  A question, though - I assume this will branch off master now, not from
> the beta tag?  Given that in NetCAT we were testing the beta, I assume
> there is nothing you'd consider "too destabilizing"  between then and now?
>
> Best wishes,
>
> Neil
> --
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
>
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>
>

AW: Time to branch for the release candidate?

[Christian Lenz]

Master shouldn’t be that one, where the wild development is going on. Master 
should be that one which is already live.
In General, what gitflow does. Wild development is going on on the dev branch, 
for the next release. If whatever is finished, there is a release branch. After 
that, it will merged into master and created a tag.

If this is not possible, then an other solution is that develop stays clean and 
always releasable. You only work on Feature branches. After the Feature is 
finished and ready to go, it will merged into develop. Someday you can create a 
release branch of develop.


Cheer

Chris

Von: Neil C Smith
Gesendet: Dienstag, 17. April 2018 14:53
An: dev@netbeans.incubator.apache.org
Betreff: Re: Time to branch for the release candidate?

On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach <jaroslav.tul...@gmail.com>
wrote:

> Yeah, there are changes in the queue for the master branch that could be
> too destabilizing. To avoid something like that to negatively influence the
> 9.0 release, I'd suggest to create a branch release/9.0 and put only the
> safe fixes ready for 9.0 there. The wild development would continue in the
> master branch.
>

+1 to branching and that.  Longer term perhaps a more gitflow-like system
where PR's come into a develop branch too?

 A question, though - I assume this will branch off master now, not from
the beta tag?  Given that in NetCAT we were testing the beta, I assume
there is nothing you'd consider "too destabilizing"  between then and now?

Best wishes,

Neil
-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: Time to branch for the release candidate?

[Neil C Smith]

On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach 
wrote:

> Yeah, there are changes in the queue for the master branch that could be
> too destabilizing. To avoid something like that to negatively influence the
> 9.0 release, I'd suggest to create a branch release/9.0 and put only the
> safe fixes ready for 9.0 there. The wild development would continue in the
> master branch.
>

+1 to branching and that.  Longer term perhaps a more gitflow-like system
where PR's come into a develop branch too?

 A question, though - I assume this will branch off master now, not from
the beta tag?  Given that in NetCAT we were testing the beta, I assume
there is nothing you'd consider "too destabilizing"  between then and now?

Best wishes,

Neil
-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: Time to branch for the release candidate?

[Sven Reimers]

+1 for branching

Sven

John McDonnell  schrieb am Di., 17. Apr. 2018,
14:08:

> I agree,
>
> But we need to make sure that only agreed/safe fixes get merged into the
> release candidate.  Whats the criteria to use?  Only accept blocking bug
> fixes?
>
> John
>
> On 17 April 2018 at 12:10, Jaroslav Tulach 
> wrote:
>
> > Yeah, there are changes in the queue for the master branch that could be
> > too destabilizing. To avoid something like that to negatively influence
> the
> > 9.0 release, I'd suggest to create a branch release/9.0 and put only the
> > safe fixes ready for 9.0 there. The wild development would continue in
> the
> > master branch.
> >
> > Maybe this is an overkill, but it would make me feel safer.
> > -jt
> >
> >
> > 2018-04-17 13:04 GMT+02:00 Geertjan Wielenga <
> > geertjan.wiele...@googlemail.com>:
> >
> > > Hi all,
> > >
> > > Is it time to create a branch for the release candidate?
> > >
> > > If yes, or after questions and discussions, who will do it?
> > >
> > > Thanks,
> > >
> > > Gj
> > >
> >
>

Re: Time to branch for the release candidate?

[John McDonnell]

I agree,

But we need to make sure that only agreed/safe fixes get merged into the
release candidate.  Whats the criteria to use?  Only accept blocking bug
fixes?

John

On 17 April 2018 at 12:10, Jaroslav Tulach 
wrote:

> Yeah, there are changes in the queue for the master branch that could be
> too destabilizing. To avoid something like that to negatively influence the
> 9.0 release, I'd suggest to create a branch release/9.0 and put only the
> safe fixes ready for 9.0 there. The wild development would continue in the
> master branch.
>
> Maybe this is an overkill, but it would make me feel safer.
> -jt
>
>
> 2018-04-17 13:04 GMT+02:00 Geertjan Wielenga <
> geertjan.wiele...@googlemail.com>:
>
> > Hi all,
> >
> > Is it time to create a branch for the release candidate?
> >
> > If yes, or after questions and discussions, who will do it?
> >
> > Thanks,
> >
> > Gj
> >
>

Re: Time to branch for the release candidate?

[Jaroslav Tulach]

Yeah, there are changes in the queue for the master branch that could be
too destabilizing. To avoid something like that to negatively influence the
9.0 release, I'd suggest to create a branch release/9.0 and put only the
safe fixes ready for 9.0 there. The wild development would continue in the
master branch.

Maybe this is an overkill, but it would make me feel safer.
-jt


2018-04-17 13:04 GMT+02:00 Geertjan Wielenga <
geertjan.wiele...@googlemail.com>:

> Hi all,
>
> Is it time to create a branch for the release candidate?
>
> If yes, or after questions and discussions, who will do it?
>
> Thanks,
>
> Gj
>

Time to branch for the release candidate?

[Geertjan Wielenga]

Hi all,

Is it time to create a branch for the release candidate?

If yes, or after questions and discussions, who will do it?

Thanks,

Gj