This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Update centre should not be used with nightly builds in sense of updating. "Content on update center is tightened to specific build. It means if you one day install build, and meanwhile new build is produced and you see in your build available updates, then by installing updates you would mix binaries of build n with build n+1, which is not a good idea" as Thomas Musil explained. [1] However, one might see notification in IDE: 11 updates found. Click here to make your IDE up to date. Anyone who does not know that nightly builds should not be updated will click on the link to make IDE up to date, ending with unusable IDE. This question is reoccurring and disabling update notifications in nightly builds will make the end to this problem. [1] http://netbeans-org.1045718.n5.nabble.com/70cat-No-nightly-builds-tp3313132p3331748.html
If it is true that the content on the update center is tied to a specific build, it would make sense to use a respective build ID to identify matching updates. If then each nightly build had its own build ID, it would never find any updates unless they were specifically for this build. What I'm saying is: Instead of turning off updates for nightly builds, do the smart thing and correctly identify which updates are applicable to which build.
(In reply to comment #1) > If it is true that the content on the update center is tied to a specific > build, it would make sense to use a respective build ID to identify matching > updates. If then each nightly build had its own build ID, it would never find > any updates unless they were specifically for this build. > > What I'm saying is: Instead of turning off updates for nightly builds, do the > smart thing and correctly identify which updates are applicable to which build. I will not mind if it is feasible. However, nightly builds are not meant to last but to be deleted and installed each day, therefore I see no point in updating nightly build at all.
(In reply to comment #1) > What I'm saying is: Instead of turning off updates for nightly builds, do the > smart thing and correctly identify which updates are applicable to which build. +1 Update functionality should be part of our testing. This would allow to provide dummy updates, just for testing. If disabled, there would be no testing until the final release :-(
I find the update notifications useful for nightly builds. I normally download and install a new build twice a week and whenever I get an update notification (I assume it's time update again, even if I just did it).
Created attachment 110742 [details] a possible solution for supress updates To suppress update notification just run IDE with a switch "-J-Dplugin.manager.check.updates=false", it works since NetBeans 6.0. Patch in the attachment makes it as default option in daily/nightly builds.
(In reply to comment #4) > I find the update notifications useful for nightly builds. I normally download > and install a new build twice a week and whenever I get an update notification > (I assume it's time update again, even if I just did it). As far as I can understand your assumption is wrong. :)
(In reply to comment #5) > Created an attachment (id=110742) [details] > a possible solution for supress updates > > To suppress update notification just run IDE with a switch > "-J-Dplugin.manager.check.updates=false", it works since NetBeans 6.0. Patch in > the attachment makes it as default option in daily/nightly builds. Is there any particular reason why not to make it default in nightly builds?
The option is now in netbeans.conf for daily dev builds. http://hg.netbeans.org/core-main/rev/41d7b2713792 It works for users with fresh userdirs. With an older userdir the updates are still displayed on the status line.
core-main/rev/a85c4eda82f1 suppresses the notification in older userdirs too
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/41d7b2713792 User: Antonin Nebuzelsky <anebuzelsky@netbeans.org> Log: #201745: Turn off update notifications in nightly builds
Was this change really necessary? The dev update center will certainly not offer all changes made in dev sources - only those which are accompanied by a spec version increase; but those updates which *are* offered ought to be always be safe to install. (If not, http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/7936/testReport/org.netbeans.nbbuild/VerifyUpdateCenter/diachronicConsistency/ is not doing its job.) musilt2 implies in the NetCAT thread that the problem was some sort of user error (accepting updates), whereas a P1 bug should have been filed against the responsible module. And what about dev builds into which experimental modules, or indeed any modules not in the standard distro, have been added? Certainly you want to be notified about available updates for these! But now you have to remember to go to Help > Check for Updates periodically (even though "Check Interval" continues to show e.g. "Every Day" in the UI). That seems like a regression.
(In reply to comment #11) > Was this change really necessary? I also do not think so. > The dev update center will certainly not > offer all changes made in dev sources - only those which are accompanied by a > spec version increase; but those updates which *are* offered ought to be always > be safe to install. (If not, > http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/7936/testReport/org.netbeans.nbbuild/VerifyUpdateCenter/diachronicConsistency/ > is not doing its job.) musilt2 implies in the NetCAT thread that the problem > was some sort of user error (accepting updates), whereas a P1 bug should have > been filed against the responsible module. > > And what about dev builds into which experimental modules, or indeed any > modules not in the standard distro, have been added? Certainly you want to be > notified about available updates for these! But now you have to remember to go > to Help > Check for Updates periodically (even though "Check Interval" > continues to show e.g. "Every Day" in the UI). That's true, people outside NetCat mailing list can find out it as defect. Either we have to change the default period to NEVER for nightly builds to make it consistent or, better, rollback this change completely. > That seems like a regression.
(In reply to comment #11) > Was this change really necessary? It was confusing by all means. It appears that confusion is coming from you guys having different opinions on the problem: Thomas is saying that using update centre from the development builds is not such a good idea and that basically update centre should not be used while you have a different opinion. In short: If there is notification that IDE should be updated then the user should be free to update the IDE without hesitation. Particularly confusing moment was that once the IDE has been updated the user will consider that the IDE is up to date and that there is no need to install new version (nightly build). IMHO this is not regression. If the user has such esoteric modules installed then by all means such user will remember to update the particular module. > The dev update center will certainly not > offer all changes made in dev sources - only those which are accompanied by a > spec version increase; but those updates which *are* offered ought to be always > be safe to install. (If not, > http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/7936/testReport/org.netbeans.nbbuild/VerifyUpdateCenter/diachronicConsistency/ > is not doing its job.) musilt2 implies in the NetCAT thread that the problem > was some sort of user error (accepting updates), whereas a P1 bug should have > been filed against the responsible module. > > And what about dev builds into which experimental modules, or indeed any > modules not in the standard distro, have been added? Certainly you want to be > notified about available updates for these! But now you have to remember to go > to Help > Check for Updates periodically (even though "Check Interval" > continues to show e.g. "Every Day" in the UI). That seems like a regression.
(In reply to comment #13) > If there is notification that IDE should be updated then the user > should be free to update the IDE without hesitation. Even if there is no such notification, the user should be free to accept any updates found by Help > Check for Updates. In other words, disabling notifications does not relieve NB developers of the responsibility for ensuring that all proffered updates are consistent to a basic extent: version dependencies satisfied, linkage errors avoided. > once the IDE has been updated the user will consider that the > IDE is up to date and that there is no need to install new version (nightly > build). Agreed that this is a potential source of confusion. I think it simply points to the need for education on the part of dev build users that AU is not a replacement for downloading fresh builds (unless and until we implement a system [1] of pushing modules modified in sources to dev AU). > If the user has such esoteric modules installed The problem applies to _any_ plugins outside the standard NB distribution that may have been installed. > such user will remember to update the particular module. I have a number of plugins installed in my dev build's user directory and have found it impossible to remember to run Check for Updates routinely. Nor would I even know I needed to do that if I had not read this bug report, since "Check Interval" continues to say "Every Day" in Plugin Manager's Settings panel. [1] http://wiki.netbeans.org/AggregatingUC#Version-aware_push