Re: Lets talk about JDK 8 (new year edition)
I have data on the Snap releases. I know it is highly non representative and due to the auto update nature of Snaps it is really in favor of latest stable so: Rounding on hundreds: out of 33600 installs 32800 is using NetBeans 16, 200 NetBeans 15, 200 NetBeans 17-rc2, 200 NetBeans 12.0 and the rest are just fragments. On 2/6/23 17:57, Ernie Rael wrote: On 23/02/05 7:52 AM, Neil C Smith wrote: On Wed, 11 Jan 2023 at 11:03, Neil C Smith wrote: Yes, the sooner we can update what was agreed for NB13, the better. But that requires notice (so not NB17, and possibly not NB18), a new lazy consensus proposal, and no vetoes! Let's talk some more about JDK 8 ... and JDK 11 for that matter! :-) Maybe somewhat off topic, but Is there any data on the distribution of NetBeans versions in use? In particular I'm wondering about how to set minimum supported NetBeans version for plugin -ernie While the immediate NB17 issue was resolved, but given comments in other threads more recently, it would be good not to let the discussion on when and how to drop the rest of our JDK 8 support. In particular with JDK 21 (the next LTS) already on the horizon later this year. In the past I believe NetBeans supported current and previous Java releases? Now might be the time to consider what our long term plan with the new JDK release schedule should be too. Previously we've discussed LTS-1, LTS and current as perhaps the limit of our capacity, for both maintaining and testing infrastructure? Firstly, do we look to move to JDK 11 as the baseline release for compilation, and running of all modules from NetBeans 19 (Aug 2023)? That allows us to advertise the NetBeans 18 platform as the last release that will support JDK 8, as well as give us time to look at remaining problems with tests? Secondly, should we at the same time advertise a plan for future JDK support so that IDE and platform users have something concrete to work with? This could be based on LTS-1, LTS and current. We could take the release of JDK 22, when JDK 21 stops being "current", as the point where we drop support for JDK 11. That would have NetBeans 22 (May 2024) requiring JDK 17 for build and run. We have required JDK 11 for build some time before dropping JDK 8 support. Do we go back to min JDK for build and run being the same again, moving build and run min JDK 17 at the same time, or staggered? Thoughts? Concerns? Alternatives? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
On 07.02.23 02:57, Ernie Rael wrote: On 23/02/05 7:52 AM, Neil C Smith wrote: On Wed, 11 Jan 2023 at 11:03, Neil C Smith wrote: Yes, the sooner we can update what was agreed for NB13, the better. But that requires notice (so not NB17, and possibly not NB18), a new lazy consensus proposal, and no vetoes! Let's talk some more about JDK 8 ... and JDK 11 for that matter! :-) Maybe somewhat off topic, but Is there any data on the distribution of NetBeans versions in use? NetBeans itself is collecting no data. Not sure if there are any metrics from the plugin portal catalog queries. In particular I'm wondering about how to set minimum supported NetBeans version for plugin I would simply pick a recent version and not worry about it. Maybe your plugin encourages someone to upgrade NetBeans to a supported version :) -mbien -ernie While the immediate NB17 issue was resolved, but given comments in other threads more recently, it would be good not to let the discussion on when and how to drop the rest of our JDK 8 support. In particular with JDK 21 (the next LTS) already on the horizon later this year. In the past I believe NetBeans supported current and previous Java releases? Now might be the time to consider what our long term plan with the new JDK release schedule should be too. Previously we've discussed LTS-1, LTS and current as perhaps the limit of our capacity, for both maintaining and testing infrastructure? Firstly, do we look to move to JDK 11 as the baseline release for compilation, and running of all modules from NetBeans 19 (Aug 2023)? That allows us to advertise the NetBeans 18 platform as the last release that will support JDK 8, as well as give us time to look at remaining problems with tests? Secondly, should we at the same time advertise a plan for future JDK support so that IDE and platform users have something concrete to work with? This could be based on LTS-1, LTS and current. We could take the release of JDK 22, when JDK 21 stops being "current", as the point where we drop support for JDK 11. That would have NetBeans 22 (May 2024) requiring JDK 17 for build and run. We have required JDK 11 for build some time before dropping JDK 8 support. Do we go back to min JDK for build and run being the same again, moving build and run min JDK 17 at the same time, or staggered? Thoughts? Concerns? Alternatives? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
On 23/02/05 7:52 AM, Neil C Smith wrote: On Wed, 11 Jan 2023 at 11:03, Neil C Smith wrote: Yes, the sooner we can update what was agreed for NB13, the better. But that requires notice (so not NB17, and possibly not NB18), a new lazy consensus proposal, and no vetoes! Let's talk some more about JDK 8 ... and JDK 11 for that matter! :-) Maybe somewhat off topic, but Is there any data on the distribution of NetBeans versions in use? In particular I'm wondering about how to set minimum supported NetBeans version for plugin -ernie While the immediate NB17 issue was resolved, but given comments in other threads more recently, it would be good not to let the discussion on when and how to drop the rest of our JDK 8 support. In particular with JDK 21 (the next LTS) already on the horizon later this year. In the past I believe NetBeans supported current and previous Java releases? Now might be the time to consider what our long term plan with the new JDK release schedule should be too. Previously we've discussed LTS-1, LTS and current as perhaps the limit of our capacity, for both maintaining and testing infrastructure? Firstly, do we look to move to JDK 11 as the baseline release for compilation, and running of all modules from NetBeans 19 (Aug 2023)? That allows us to advertise the NetBeans 18 platform as the last release that will support JDK 8, as well as give us time to look at remaining problems with tests? Secondly, should we at the same time advertise a plan for future JDK support so that IDE and platform users have something concrete to work with? This could be based on LTS-1, LTS and current. We could take the release of JDK 22, when JDK 21 stops being "current", as the point where we drop support for JDK 11. That would have NetBeans 22 (May 2024) requiring JDK 17 for build and run. We have required JDK 11 for build some time before dropping JDK 8 support. Do we go back to min JDK for build and run being the same again, moving build and run min JDK 17 at the same time, or staggered? Thoughts? Concerns? Alternatives? Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Issue management issues (meta-issues?!)
On 23/02/06 12:34 PM, Neil C Smith wrote: On Sat, 4 Feb 2023 at 00:51, Michael Bien wrote: yeah it seems like nobody is using the triage label the way it was originally intended. We could probably just remove that label (or don't let gh set it by default at the very least). If something is missing labels it is probably not triaged. I'd prefer to keep a label. Possibly even more likely to accumulate unanswered issues without? One of the original intentions was to allow us to use GH actions for some automation. We could remove the label automatically if a committer replies? I think "NeedsTriage" has a meaning beyond that someone has made a comment. How about "NeedsTriage" can only be taken away when either "Bug" or "FeatureRequest" or ??? is added. -ernie Could even email a report of older issues without a response on a regular basis? and probably more. Should we prefix all issue specific labels with 'issue:'? So that they are easier to find in the search? Mentioning 'issue' in the label description would have a similar effect. Possibly would help. Need to check whether they're used, and make sure we don't rename any with special meaning though. Incidentally, also need to handle the fact that GH changed the forms so that required dropdowns are being populated - I think that's why we've had more offers of PRs! :-) Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
On 07.02.23 00:43, Neil C Smith wrote: On Mon, 6 Feb 2023, 22:22 Michael Bien, wrote: What is needed is to communicate that it is ok to upgrade everything to JDK11 - which would open the flood gates. Maybe. But do we really want a flood of modules with non-default configuration? there is no default configuration for source/target yet - that was just an idea. again: if we can do everything in one go -> even better we can probably set the module manifest to JDK 11 in one go for example which would be the easy part. The policy was as far as I remember to be ok with new modules starting out on JDK 11, old modules have to be discussed before move - that is too much work since NB has ~450 sub-projects. Changing this will probably require a vote In my mind it requires a lazy consensus thread, like the previous one. ie. A proposal with no vetoes. Vetoes of course being based on technical arguments or alternative approaches to address the problem. I'm happy to write something up if no-one else does first. I restarted this discussion to try and work out what that should look like. this should be goal of course. Lets move everything to JDK 11 unless it is used by the platform. Why do you think the platform should be special cased? I don't think it necessarily should. But it currently is. Platform has to run on JDK 8+. IDE runs on JDK 11+ since NB 12.6. you just wrote: "a) support running the platform on JDK 8 until NetBeans 19" -> special case in build, CI etc until NB 19 is out after that we should sync everything 11. But there is no technical reason to wait with IDE modules till that date, if someone wants to move a module for NB 18 it shouldn't be a big deal. Not a lot would prevent us to require JDK 21 for the IDE once it is out some time in future (assuming tests work). But I imagine there will be resistance to do the same for the platform. So the same situation will likely repeat again. Platform is a lib, the IDE is a tool/product. The distinction will likely always cause some friction in runtime requirements. I don't think a forward looking statement regarding building requirements of the IDE is needed tbh. If its left out we don't have to define exceptions. In many respects I agree. The important part of any statement is runtime compatibility. However ASF releases sources, so there are some arguments for good advance communication of build requirements too? if it works we can do it all at once. I am just a bit skeptical that it will "just work" given how many edge cases and custom javac calls the build has to deal with. True, but that's what I mean by opt-out vs opt-in. Why not keep the custom configuration for the edge cases? opt-ins can be trivially removed with search and replace once the default is bumped. This shouldn't be the reason to stop an IDE module from requiring JDK 11 for another year. We would have to do this anyway since there would be already opt-ins to remove once we add a default config due to already existing modules which require JDK 11. What is your concern? No reason not to try. This is also one of the more time consuming tasks. Since you have to run a full build and then check via a script that none of the class files suddenly starts having their version set to 65. Good job we have a test for that already then! it is very rudimentary https://github.com/apache/netbeans/pull/5122#issuecomment-1359902237 -mbien Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
On Mon, 6 Feb 2023, 22:22 Michael Bien, wrote: > What is needed is to communicate that it is ok to upgrade everything to > JDK11 - which would open the flood gates. > Maybe. But do we really want a flood of modules with non-default configuration? > The policy was as far as I remember to be ok with new modules starting > out on JDK 11, old modules have to be discussed before move - that is > too much work since NB has ~450 sub-projects. > > Changing this will probably require a vote In my mind it requires a lazy consensus thread, like the previous one. ie. A proposal with no vetoes. Vetoes of course being based on technical arguments or alternative approaches to address the problem. I'm happy to write something up if no-one else does first. I restarted this discussion to try and work out what that should look like. this should be goal of course. Lets move everything to JDK 11 unless it > is used by the platform. > Why do you think the platform should be special cased? I don't think a forward looking statement regarding building > requirements of the IDE is needed tbh. If its left out we don't have to > define exceptions. > In many respects I agree. The important part of any statement is runtime compatibility. However ASF releases sources, so there are some arguments for good advance communication of build requirements too? > > if it works we can do it all at once. I am just a bit skeptical that it > will "just work" given how many edge cases and custom javac calls the > build has to deal with. > True, but that's what I mean by opt-out vs opt-in. Why not keep the custom configuration for the edge cases? > No reason not to try. This is also one of the more time consuming tasks. > Since you have to run a full build and then check via a script that none > of the class files suddenly starts having their version set to 65. > Good job we have a test for that already then! Best wishes, Neil
Re: Issue management issues (meta-issues?!)
On 06.02.23 21:34, Neil C Smith wrote: On Sat, 4 Feb 2023 at 00:51, Michael Bien wrote: yeah it seems like nobody is using the triage label the way it was originally intended. We could probably just remove that label (or don't let gh set it by default at the very least). If something is missing labels it is probably not triaged. I'd prefer to keep a label. Possibly even more likely to accumulate unanswered issues without? One of the original intentions was to allow us to use GH actions for some automation. We could remove the label automatically if a committer replies? in theory yes. In practice: - the workflow might need write permission for that, current workflows are intentionally kept without that permission (this is also the apache default last time i checked) - the workflow would have to check who is an apache committer Could even email a report of older issues without a response on a regular basis? please no :) Not to me at least. gh CLI can probably generate that list. I used it from scripts for another project before. gh issue list --label "needs:triage" --search "sort:created-asc" second entry point is via the search (has filters for comment count etc): gh search issues [] [flags] (don't run more than 5k queries per hour) and probably more. Should we prefix all issue specific labels with 'issue:'? So that they are easier to find in the search? Mentioning 'issue' in the label description would have a similar effect. Possibly would help. Need to check whether they're used, and make sure we don't rename any with special meaning though. yeah. Ideally they shouldn't show up in main.yml and release.yml... and doesn't hurt to check the rest too. Adding a label description should be always safe. Incidentally, also need to handle the fact that GH changed the forms so that required dropdowns are being populated - I think that's why we've had more offers of PRs! :-) we should interpret this as commitment and let a github action ask the user once per week where the PR is :) -mbien Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
On 06.02.23 21:23, Neil C Smith wrote: On Sun, 5 Feb 2023 at 19:12, Michael Bien wrote: would be great. The JDK 8 -> 11 step is in many ways "special" since so much changed between those two LTS releases. Well, yes, otherwise we might have done this some time ago! :-) I don't think we have to move everything to JDK 11 at once - ... We can move modules to JDK 11 incrementally until nothing is left on JDK 8. Isn't that the status quo? no it isn't. This is met by very high resistance. We have workarounds in the maven-indexer space exclusively to keep JDK 8 compatibility and keep using an EOL lucene lib. Another (smaller) example was a bugfix i recently reviewed which fixed java version number parsing and basically replicates an API which is already in JDK 11 - there too we didn't bump the version. What is needed is to communicate that it is ok to upgrade everything to JDK11 - which would open the flood gates. Nobody sets release=8 for the extra challenge :). The policy was as far as I remember to be ok with new modules starting out on JDK 11, old modules have to be discussed before move - that is too much work since NB has ~450 sub-projects. Changing this will probably require a vote - I don't know. Users already know that they have to run on JDK 11+ since this is on the download page since 12.6 I believe - nothing changes there. Having a few modules opting in to JDK 11 seems a bit different to moving towards having everything opt-in and losing the benefits of a default configuration. At some point we surely need to move the default configuration up to JDK 11? this should be goal of course. Lets move everything to JDK 11 unless it is used by the platform. We don't have to make this a hard rule. I would move to the next LTS as soon it makes sense and we are actually able to do it. Once this works we can make a rule out of it :) Who said "hard rule"? Our release schedule and process (which this ties into) was agreed to try and provide consistency and clarity for ourselves and users. But it's iterated multiple times since. Part of the thoughts on this are because OpenJDK iterated its release and support schedule. Having some principle that we can agree and can advertise to end users, particularly platform and plugin developers, has benefit. Let me reword the suggestion a little - the only two hard guarantees would be to - a) support running the platform on JDK 8 until NetBeans 19 - b) to commit to supporting building and running on JDK 11 until (at least?) NetBeans 22 / May 2024 b) should leave room for exceptions though as long the modules are optional and give convincing reasons to require JDKs >11. (gave an example before, e.g: JakartaEE 11 targeting JDK 21) I don't think a forward looking statement regarding building requirements of the IDE is needed tbh. If its left out we don't have to define exceptions. We don't need to commit to raising the bytecode version straight away, true, just it becomes an option at that point - we could also have a soft requirement as now. right i was hoping to be able to implement one 'release' property in the build which would define the default bytecode level for everything and remove the source/target properties everywhere. Modules would only define a 'release' version if they want to break that convention. Yes, saw that and totally agree. Isn't that an argument for not taking the opt-in approach above though? if it works we can do it all at once. I am just a bit skeptical that it will "just work" given how many edge cases and custom javac calls the build has to deal with. No reason not to try. This is also one of the more time consuming tasks. Since you have to run a full build and then check via a script that none of the class files suddenly starts having their version set to 65. The beauty of custom ant builds (I am kidding). We should also consider a dialog for NB 18 which warns users if they try to run NB on JDK 8 - we still don't have that dialog, I somehow keep forgetting about it and only get reminded again while reading the issue tracker during the RC phase. You and me both! :-) I'm almost thinking it might not be worth it - depends how we approach in future and whether it has re-use. well. I have a demo somewhere which downloads a runtime JDK into the netbeans folder if the version isn't right :) best regards, michael Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further
Re: Issue management issues (meta-issues?!)
On Sat, 4 Feb 2023 at 00:51, Michael Bien wrote: > yeah it seems like nobody is using the triage label the way it was > originally intended. > > We could probably just remove that label (or don't let gh set it by > default at the very least). If something is missing labels it is > probably not triaged. I'd prefer to keep a label. Possibly even more likely to accumulate unanswered issues without? One of the original intentions was to allow us to use GH actions for some automation. We could remove the label automatically if a committer replies? Could even email a report of older issues without a response on a regular basis? > and probably more. Should we prefix all issue specific labels with > 'issue:'? So that they are easier to find in the search? Mentioning > 'issue' in the label description would have a similar effect. Possibly would help. Need to check whether they're used, and make sure we don't rename any with special meaning though. Incidentally, also need to handle the fact that GH changed the forms so that required dropdowns are being populated - I think that's why we've had more offers of PRs! :-) Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
On Sun, 5 Feb 2023 at 19:12, Michael Bien wrote: > would be great. The JDK 8 -> 11 step is in many ways "special" since so > much changed between those two LTS releases. Well, yes, otherwise we might have done this some time ago! :-) > I don't think we have to move everything to JDK 11 at once - ... > We can move modules to JDK 11 incrementally until nothing is left on JDK > 8. Isn't that the status quo? Having a few modules opting in to JDK 11 seems a bit different to moving towards having everything opt-in and losing the benefits of a default configuration. At some point we surely need to move the default configuration up to JDK 11? > I thought so far that the NB VSCode extension would still have a hard > JDK 8 requirement - but I was wrong as this discussion showed, so there > is nothing stopping us from doing this except the rule we set ourself in > past. Yes, so it's hopefully time to consider the next iteration of that rule ... > We don't have to make this a hard rule. I would move to the next LTS as > soon it makes sense and we are actually able to do it. Once this works > we can make a rule out of it :) Who said "hard rule"? Our release schedule and process (which this ties into) was agreed to try and provide consistency and clarity for ourselves and users. But it's iterated multiple times since. Part of the thoughts on this are because OpenJDK iterated its release and support schedule. Having some principle that we can agree and can advertise to end users, particularly platform and plugin developers, has benefit. Let me reword the suggestion a little - the only two hard guarantees would be to - a) support running the platform on JDK 8 until NetBeans 19 - b) to commit to supporting building and running on JDK 11 until (at least?) NetBeans 22 / May 2024 We don't need to commit to raising the bytecode version straight away, true, just it becomes an option at that point - we could also have a soft requirement as now. > i was hoping to be able to implement one 'release' property in the build > which would define the default bytecode level for everything and remove > the source/target properties everywhere. Modules would only define a > 'release' version if they want to break that convention. Yes, saw that and totally agree. Isn't that an argument for not taking the opt-in approach above though? > We should also consider a dialog for NB 18 which warns users if they try > to run NB on JDK 8 - we still don't have that dialog, I somehow keep > forgetting about it and only get reminded again while reading the issue > tracker during the RC phase. You and me both! :-) I'm almost thinking it might not be worth it - depends how we approach in future and whether it has re-use. Best wishes, Neil - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: PRs and squashing
On 06.02.23 18:27, Ernie Rael wrote: Looking for clarification on some issues that arose in a side discussion in a PR.It comes down to this statement: So if I get this right, a pattern is to push several commits to a PR, then after approval, can squash locally (using mercurial in my case) and force push to the PR. There were some comments about squash/merge and how github/git commands have issues going directly to main. I got confused because I missed the "to main" versus "to PR branch" distinction. Here's my understanding: squashing and force pushing to a PR branch, in particular one that I opened, does not run into issues. And from my perspective, as someone who never pushes to master, I can ignore issues relating to peculiarities around local squash and merge pushed directly to master. right, this all has to happen in branches which are not integrated yet. Never force push to other public branches. Projects will usually have branch protection enabled to prevent that from happening. An open question. If there's a PR with multiple commits and it's approved, and I then locally squashand force push to the PR branch. Does the "Compare" button associated with the forced push still show up and have a diff with no changes (assuming, of course, that there were no changes)? right, it will show "no changes". Unless you pulled from master to update the branch for example. Then it will show (sometimes a lot of) changes even though it won't show the commits in the list since they are already in master (target branch). But if all you did is to squash and force push, it won't show any changes since it is just a diff tool which compares two branches: the one before push and the one after. -mbien Of course, depending on the situation, there are times when multiple commits in a single PR are desirable (fix+refactoring is given as an example). -ernie - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
PRs and squashing
Looking for clarification on some issues that arose in a side discussion in a PR.It comes down to this statement: So if I get this right, a pattern is to push several commits to a PR, then after approval, can squash locally (using mercurial in my case) and force push to the PR. There were some comments about squash/merge and how github/git commands have issues going directly to main. I got confused because I missed the "to main" versus "to PR branch" distinction. Here's my understanding: squashing and force pushing to a PR branch, in particular one that I opened, does not run into issues. And from my perspective, as someone who never pushes to master, I can ignore issues relating to peculiarities around local squash and merge pushed directly to master. An open question. If there's a PR with multiple commits and it's approved, and I then locally squashand force push to the PR branch. Does the "Compare" button associated with the forced push still show up and have a diff with no changes (assuming, of course, that there were no changes)? Of course, depending on the situation, there are times when multiple commits in a single PR are desirable (fix+refactoring is given as an example). -ernie
