Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 201745 - Turn off update notifications in nightly builds
Turn off update notifications in nightly builds
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Autoupdate
7.1
PC Linux
: P3 with 6 votes (vote)
: 7.1
Assigned To: Jiri Rechtacek
au-issues
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-07 13:29 UTC by schkovich
Modified: 2011-11-08 23:01 UTC (History)
6 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
a possible solution for supress updates (1.44 KB, patch)
2011-09-14 11:52 UTC, Jiri Rechtacek
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description schkovich 2011-09-07 13:29:53 UTC
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
Comment 1 matthies 2011-09-07 13:42:15 UTC
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.
Comment 2 schkovich 2011-09-07 15:24:20 UTC
(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.
Comment 3 ulfzibis 2011-09-08 09:55:31 UTC
(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 :-(
Comment 4 paolosca 2011-09-13 05:11:14 UTC
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).
Comment 5 Jiri Rechtacek 2011-09-14 11:52:20 UTC
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.
Comment 6 schkovich 2011-09-14 12:13:16 UTC
(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. :)
Comment 7 schkovich 2011-09-14 12:14:10 UTC
(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?
Comment 8 Antonin Nebuzelsky 2011-09-15 11:06:55 UTC
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.
Comment 9 Jiri Rechtacek 2011-09-15 12:05:23 UTC
core-main/rev/a85c4eda82f1 suppresses the notification in older userdirs too
Comment 10 Quality Engineering 2011-09-17 14:23:00 UTC
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
Comment 11 Jesse Glick 2011-09-20 20:23:28 UTC
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.
Comment 12 Jiri Rechtacek 2011-09-21 07:27:51 UTC
(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.
Comment 13 schkovich 2011-09-21 09:21:30 UTC
(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.
Comment 14 Jesse Glick 2011-10-28 22:16:22 UTC
(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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo