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.

Bug 208627 - Update IDE branding after updating to newer update/patch release via update center (e.g. from 7.1 to 7.1.1)
Summary: Update IDE branding after updating to newer update/patch release via update c...
Status: RESOLVED FIXED
Alias: None
Product: ide
Classification: Unclassified
Component: Code (show other bugs)
Version: 7.1
Hardware: All All
: P3 normal with 11 votes (vote)
Assignee: Antonin Nebuzelsky
URL:
Keywords:
: 211049 211066 212703 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-02-20 08:56 UTC by host
Modified: 2013-07-22 16:06 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Netbeans 7.1.2 showing different versions in caption and about box (432.39 KB, image/png)
2012-04-24 05:58 UTC, alied
Details
Netbeans 7.1.2 about box in Windows XP (256.22 KB, image/png)
2012-04-24 15:15 UTC, alied
Details

Note You need to log in before you can comment on or make changes to this bug.
Description host 2012-02-20 08:56:29 UTC
The current "design" regarding the branding of the IDE after updating to a newer update/patch release via update center is misleading: Currently, after such an update, e.g. from 7.1 to 7.1.1, then the branding remains that of the former version, e.g. 7.1 in this case.

From my point of view, the IDE needs to fully reflect its current update/version state!

This behavior is especially puzzling if you update your IDE (and you still get the 7.1 branding) and your next door colleague installs the IDE freshly and gets the correct branding (i.e. the 7.1.1). Then you really start to think: "Did the update really work correctly?"
Comment 1 Jiri Rechtacek 2012-02-20 09:11:46 UTC
IMHO it's correct. You have still NetBeans 7.1 Final Build with patch1 applied. NetBeans 7.1.1 is a different build (however is built on top of same sources in fact).
Comment 2 schkovich 2012-02-20 10:15:12 UTC
(In reply to comment #1)
> IMHO it's correct. You have still NetBeans 7.1 Final Build with patch1 applied.
> NetBeans 7.1.1 is a different build (however is built on top of same sources in
> fact).

Is there a difference from the user point of view between those two (final build + patch vs. new 7.1.1 build)? If not, then splash screen should be updated. Effectively it is NetBeans 7.1.1.

Alternatively splash screen might be updated to NetBeans 7.1 patch x.y.z applied or similar.
Comment 3 host 2012-02-20 10:39:14 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > IMHO it's correct. You have still NetBeans 7.1 Final Build with patch1 applied.
> > NetBeans 7.1.1 is a different build (however is built on top of same sources in
> > fact).
> 
> Is there a difference from the user point of view between those two (final
> build + patch vs. new 7.1.1 build)? If not, then splash screen should be
> updated. Effectively it is NetBeans 7.1.1.
> 
> Alternatively splash screen might be updated to NetBeans 7.1 patch x.y.z
> applied or similar.

I understand Jiri's point if there is a *technical* difference between an updated version and a completely new build. BUT for the *end user* this (hidden) difference is not obvious at all and should thus not be visible through different branding.
Comment 4 host 2012-02-20 10:59:44 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > IMHO it's correct. You have still NetBeans 7.1 Final Build with patch1 applied.
> > > NetBeans 7.1.1 is a different build (however is built on top of same sources in
> > > fact).
> > 
> > Is there a difference from the user point of view between those two (final
> > build + patch vs. new 7.1.1 build)? If not, then splash screen should be
> > updated. Effectively it is NetBeans 7.1.1.
> > 
> > Alternatively splash screen might be updated to NetBeans 7.1 patch x.y.z
> > applied or similar.
> 
> I understand Jiri's point if there is a *technical* difference between an
> updated version and a completely new build. BUT for the *end user* this
> (hidden) difference is not obvious at all and should thus not be visible
> through different branding.

The last sentence should obviously read "...SHOULD BE visible through different branding"
Comment 5 Petr Somol 2012-02-20 11:57:39 UTC
The points raised in Comment 2 and 3 are indeed important. From user experience point of view the technical process differences in NB update vs. separate build processes should not be exposed if the resulting NB installation is functionally identical.

Question to Jiri - is it technically so, that the exact definition of "being 7.1.1" depends only on the versions of installed modules ? I can imagine that installing a fresh 7.1.1 leads to NB with slightly different combination of module versions than would be the case of updating a 7.1, but if all modules in a NB installation have versions larger or equal to those distributed with 7.1.1, it is effectively 7.1.1.

But I also noticed in the past that NB showed the current effective version in its main window title - take a look after the update which version is claimed there. Does it still work like that ? If so, then this is inconsistent with what the user is presented with in the splash screen, and this should indeed be updated as well.

Re-assigning to Jiri for further evaluation. Sorry it it is out of your scope, I wasn't sure whether this belonged under installer or not..
Comment 6 Jiri Rechtacek 2012-02-23 08:04:58 UTC
Nothing to do with Autoupdate/Plugin Manager code. Just needs to change the branding in NB7.1-patch1.
Davide, reassign to someone who is responsible for 7.1.1 branding? Thanks
Comment 7 David Strupl 2012-02-24 08:57:37 UTC
I think this is handled by Tonda but at the same time I don't think we would like to change this. Marking the report as wont fix. host, thanks for the report, the developers are aware of this but decided to just make a note in the release notes.
Comment 8 swpalmer 2012-02-25 15:32:59 UTC
"I don't think we would like to change this."

Why?????

Are there any NB users that agree with this?  Many have spoken up to say it is confusing.  What is the benefit?
Comment 9 host 2012-02-25 19:20:55 UTC
Please, do not don't take my opinion as an offense but - speaking as a developer myself - developers are sometimes not the most "sensitive" people to such seemingly smallish UI issues. ...but which are sometimes quite big issues for the actual end user!

Therefore I reopen the issue thinking about the possibility of assigning it to (someone from) your "branding" team for consideration from a non-developer point-of-view. When reopening the issue I take into account the isuue's votes and the mails about this topic on the NetCAT list.

Also, if it is not possible to have the desired behavior in the 7.1.1 patch release then it would be really nice at least to see it later (e.g. 7.2.1).
Comment 10 David Strupl 2012-02-26 09:55:09 UTC
Hello,

I apologize but I should have explained better why the decision was made.

1. It is now already assigned to our "branding" team consisting of Antonin. BTW the rest of the "branding team" is an external graphic artist who we ask (and pay for) actual images.

2. If you update all (updatable) modules from the update center you will still not have "real" 7.1.1 - the biggest part of the 7.1.1 changes is upgrade of GlassFish server to version 3.1.2 and Java ME SDK to version 3.0.5. Both of these changes are *not* delivered via update center but only as part of installation. Thus what you have after all module updates from update center is what I would call "updated 7.1 version".

3. Can we please leave the issue a wont fix since it does not make much sense even for the future versions? I mean even in the future I don't think that it will be correct to mark the version by branding that is not in synch with what we distribute as a dot dot release.

Best regards,

David
Comment 11 swpalmer 2012-02-26 14:44:33 UTC
I won't' reopen the bug, but I still think more discussion on this might be good.
For example:
 
Glassfish and Java ME are optional.  What if they weren't installed in the first place?

Is there a technical reason that Glassfish and Java ME will never be available from the update centre?  Perhaps they should be, and if that changes this issue should be revisited.

Would it be possible to somehow trigger a download and full install via an upgrade module made available via update centre?

Some users might prefer that when a new release is available that they are given the option of either updating the modules -OR- they can choose to follow a link to download the full release.  In other words they should be made aware from within the NB update mechanism that a new full release is available as an alternative to doing module updates.
Comment 12 David Strupl 2012-02-26 15:42:04 UTC
It is not possible to update 3rd party components that might contain their own update mechanism different from NetBeans. From our (NetBeans) point of view these are installed via installer launching their own installer. Even if we would not have such components it might not be correct to upgrade main branding since the user might decide to install only subset of the updated modules and if by some accident (s)he would install the main branding module and not the others he would end up having the IDE branded to the new version while in fact he would have partially updated older version. The only correct scenario would be to supply the branding if the module containing it would force *all* modules to be upgraded. I am not sure we want to attempt that.
Comment 13 schkovich 2012-02-26 21:03:15 UTC
(In reply to comment #12)
> It is not possible to update 3rd party components that might contain their own
> update mechanism different from NetBeans. From our (NetBeans) point of view
> these are installed via installer launching their own installer. Even if we
> would not have such components it might not be correct to upgrade main branding
> since the user might decide to install only subset of the updated modules and
> if by some accident (s)he would install the main branding module and not the
> others he would end up having the IDE branded to the new version while in fact
> he would have partially updated older version. The only correct scenario would
> be to supply the branding if the module containing it would force *all* modules
> to be upgraded. I am not sure we want to attempt that.

I see your point. However problem is still there. Users, including myself, are not confused by the IDE branding but with concept of the IDE update from withing the IDE itself. As far as I can understand this mechanism is actually a advanced way of updating the IDE and it should not be a preferred way of updating the IDE. Thank you for clarification.
Comment 14 host 2012-04-12 07:46:25 UTC
Now that the release of version 7.1.2 is around the corner, the branding issue gets even more "interesting" in my opinion:

First, one performs a clean install of 7.1.1 - a patch release - and one (correctly) get the branding of that release.

Now you use the update center to update to 7.1.2 - another patch release - and you keep the branding of the former patch release.

I still remember your reasoning behind your decision but it really confuses me - and at least one other user on the NetCAT mailing list who "complaint" about the "wrong" old branding as well.

If you want to stick to a branding after an update then at least not to the branding of the previous patch release - rather then ONLY use and keep the branding of the major release (also for the installer).

And also, what happens to the branding when we update to 7.2 via the update center? ...or will that not be possible?

(Sorry if I am inadequately reopen this issue but I do so to solicit some feedback from the followers and voters of this issue.)
Comment 15 Jiri Rechtacek 2012-04-12 08:47:03 UTC
*** Bug 211066 has been marked as a duplicate of this bug. ***
Comment 16 Marian Mirilovic 2012-04-12 09:07:18 UTC
*** Bug 211049 has been marked as a duplicate of this bug. ***
Comment 17 Marian Mirilovic 2012-04-12 09:11:37 UTC
(In reply to comment #14)
> And also, what happens to the branding when we update to 7.2 via the update
> center? ...or will that not be possible?

No, we do not support updates from one major release to another one.


> (Sorry if I am inadequately reopen this issue but I do so to solicit some
> feedback from the followers and voters of this issue.)

No problem, I understand all your points, and I would like to keep the discussion open, but from IDE perspective ... you are really not upgrading to 7.1.2 ... you are upgrading just subset of modules of the IDE you have previously installed (7.1 or 7.1.1) ... that's the main and only one reason we are staying with previous branding.
Comment 18 schkovich 2012-04-12 10:20:09 UTC
(In reply to comment #17)
> (In reply to comment #14)
> > And also, what happens to the branding when we update to 7.2 via the update
> > center? ...or will that not be possible?
> 
> No, we do not support updates from one major release to another one.
> 
> 
> > (Sorry if I am inadequately reopen this issue but I do so to solicit some
> > feedback from the followers and voters of this issue.)
> 
> No problem, I understand all your points, and I would like to keep the
> discussion open, but from IDE perspective ... you are really not upgrading to
> 7.1.2 ... you are upgrading just subset of modules of the IDE you have
> previously installed (7.1 or 7.1.1) ... that's the main and only one reason we
> are staying with previous branding.
Is there a way to clearly state that when updating from the IDE one will not end having actually new IDE version e.g. 7.1.2 but patched version 7.1.1?
Is it possible to update branding saying NB 7.1.1 patch w.h.a.t.e.v.e.r?
Comment 19 host 2012-04-12 10:42:27 UTC
@Marian: In regard to the second part of your comment, you are certainly technically right. But from a user perspective, when I install only the NB 7.1.1 "Java SE" package (in contrast to e.g. the "Java EE" one) then I do that on purpose and would probaly do the same for a clean 7.1.2 install.

Therefore, in the case of updating from 7.1.1 to 7.1.2, I would most likely only be interested in update to the installed modules anyway. ...and if this is not the case, then I would use the Plugins-Center to install the missing packages from there.

(I know you also updated the external GlassFish server inbetween 7.1 and 7.1.1 and this is problematic. But can't there also be a "trigger" to download such external artifacts from the update center as well?)
Comment 20 ulfzibis 2012-04-12 11:00:22 UTC
I can't think on any other product, that behaves like that. IMO NetBeans follows a rare politics here.

Which version should one specify in a bug report on a updated IDE 7.1, which is technically a 7.1.2, but not branded as that?
Comment 21 alied 2012-04-12 14:24:57 UTC
Another approach would be versions like M.n u#, e.g 7.1u2, à la Java
Comment 22 ulfzibis 2012-04-17 22:11:34 UTC
Isn't this bug a duplicate of bug 211076 ?
Comment 23 Antonin Nebuzelsky 2012-04-18 12:52:58 UTC

*** This bug has been marked as a duplicate of bug 211076 ***
Comment 24 host 2012-04-18 13:22:52 UTC
As Marian puts it in the description of her issue 211076 "see issue 208627 ... and please use THAT issue for any further discussion, do not put it here, thanks in advance."

Thus I reopen this issue at hand to keep discussion alive here. In the case that Marian, as the creater of the later issue sees it appropriate, she can close this issue.
Comment 25 alied 2012-04-24 05:58:19 UTC
Created attachment 118670 [details]
Netbeans 7.1.2 showing different versions in caption and about box
Comment 26 alied 2012-04-24 05:59:18 UTC
I was checking on my upgraded 7.1.1 to 7.1.2 on Linux, and I found this (see
attached image):
the about box says "NetBeans IDE 7.1.1 (Build 201202271535)", while the main
window caption (see the background; I have set my non-focused windows to be
translucid andthat is not always a good idea) says "Netbeans Platform 7.1.2"

Unless I screwed something, that is a inconsistent behaviour (which I just
happen to notice).

Has anybody else noticed this?
Comment 27 host 2012-04-24 08:46:30 UTC
This issue here gets more interesting with each comment added... :-) But seriously, I had a full, clean installation of NetBeans 7.1.1 and then used the update center to update the IDE. ...but for me the window still showed the version 7.1.1.
Comment 28 alied 2012-04-24 15:15:53 UTC
Created attachment 118695 [details]
Netbeans 7.1.2 about box in Windows XP
Comment 29 alied 2012-04-24 15:16:37 UTC
However, on Windows XP the behaviour is consistent (both caption and about box show the same version)
Comment 30 Jesse Glick 2012-05-24 02:15:27 UTC
*** Bug 212703 has been marked as a duplicate of this bug. ***
Comment 31 Jesse Glick 2012-05-24 02:34:51 UTC
Discussion of the versions of optional bundled third-party software is a red herring. These are conveniences and you can already check their versions via other means, or use your own copies elsewhere. Put another way, any bug report filed about NetBeans would anyway need to specify the versions of any and all _relevant_ third-party software being used during the problematic scenario, whether that software was bundled with the NB installer or not.

The real question is what to do in the case that a user decides to accept some, but not all, of the modules in patch 2. (*) Ideally you would display e.g. "32% 7.1.1 + 68% 7.1.2". Practically this is not feasible (would have to hardcode way too much information in the branding pseudomodule). So the choice is between incorrectly showing "7.1.2" for this unusual case, or incorrectly showing "7.1.1" for the perfectly normal case of someone accepting all the updates recommended to them (and thus actually having 7.1.2).

(*) Most likely due to bug #200978 - another reason to fix that.
Comment 32 ulfzibis 2012-05-24 13:05:41 UTC
(In reply to comment #31)
> So the choice is
> between incorrectly showing "7.1.2" for this unusual case, or incorrectly
> showing "7.1.1" for the perfectly normal case of someone accepting all the
> updates recommended to them (and thus actually having 7.1.2).

Maybe show 7.1.2, if all modules have been updated, but 7.1.1 if not.
Comment 33 gholmer 2012-05-24 13:15:57 UTC
(In reply to comment #31)
> The real question is what to do in the case that a user decides to accept some,
> but not all, of the modules in patch 2.

Is that even a valid use case? Why would a user do that? Does it make sense to have a big patch release like that be all-or-nothing?
Comment 34 Jesse Glick 2012-05-24 18:08:47 UTC
(In reply to comment #32)
> Maybe show 7.1.2, if all modules have been updated, but 7.1.1 if not.

Not an option with the current branding system - this is just a set of static resources (splash screens, *.properties files) which we either push changes to or we do not.

(In reply to comment #33)
> Why would a user do that?

Bug #200978 is the only plausible reason I know of: if you have some features but not others enabled from an "ergonomic" 7.1.1 build, then accept "all" updates, just the enabled features will have been updated to the 7.1.2 versions. So if you suddenly you decide you want to start working with Java ME after all, and turn it on by say running a MIDlet wizard, you will be using 7.1.1 ME support with 7.1.2 basic Java IDE code, e.g. bug #208685 would still be present though fixed in 7.1.2. Of course at that point the next update check (weekly by default?) will start offering you 7.1.2 ME updates which I would hope you would accept.
Comment 35 Marian Mirilovic 2013-07-22 16:06:27 UTC
All changes we planned to address are already in 7.3, so we are done in this area. If anybody feels it's not sufficient, please report new issue. Thanks in advance.