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 124547 - Provide module spec number in PatchesInfo page
Summary: Provide module spec number in PatchesInfo page
Status: CLOSED FIXED
Alias: None
Product: updatecenters
Classification: Unclassified
Component: Hotfixes (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Karthikeyan Rajeswaran
URL: http://www.netbeans.org/servlets/Brow...
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-01 08:55 UTC by Karthikeyan Rajeswaran
Modified: 2009-01-11 20:41 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Karthikeyan Rajeswaran 2008-01-01 08:55:41 UTC
Right now, it is not possible to know whether patches have been applied or not. Should patches info (ex:
http://wiki.netbeans.org/wiki/view/NetBeans6.0PatchesInfo) display a list of nbms and their spec numbers? This would let
the user check the spec number in the plugin manager. 

One issue we need to consider is the case regarding hidden modules, which are not displayed in the plugin manager.

One workaround is to simply connect to the update center and check the 'Updated' tab; if there are no modules listed in
the tab, then all patches have been downloaded and applied. But this may not always work; for instance if a patched
module  has been uninstalled, then connecting to the update center will display those modules under 'New' tab, rather
than 'Updated' tab. 

Another workaround:
1. Browse to the catalog:
http://www.netbeans.info/uc/show_uc_content.html
http://www.netbeans.info/uc/show_uc_content.php?ucurl=http://updates.netbeans.org/netbeans/updates/6.0/uc/final/stable/catalog.xml
2. Note down all the modules whose spec numbers have more than three digits separated by '.' . (By convention, patches
use only the fourth and/or fifth digit of module spec number) and their spec numbers.
3. Open plugin manager (Tools | Plugins) and check the 'Installed modules' tab to see if the latest version of modules
noted in spec 2 are present.
Comment 1 _ wadechandler 2008-01-01 14:57:17 UTC
It seems like this issue will become more and more prevalent as time goes by and more and more folks use NetBeans. It
seems like a better plan for how to display these things is needed in the IDE. Some how a module needs the ability to
know if it is a member of a certain "Patch Level" or something. Then the AU could show a list of Patches and which
modules are in that patch and which ones the user does and does not have installed. They can already see there is a set
of modules which they can update though, so I wonder how useful it is, but I have seen questions on nbusers more
frequently about this exact issue. 

It may just come down to eduction about the model NB employs. I mean what exactly does Patch X mean? Say there is a
Patch X released today, yet a couple other modules release their updates in a few days. Is that Patch Y? It seems the
idea of Patch 1 just got thrown out there and now folks are using the term "Patch 1" yet there is no model in place to
support the idea of Patches.

Too, most applications tell their version and information in their About screen, so throwing out the term "Patch 1"
makes people think about it. This usually tells which patches have been applied and many are used to looking there to
see that bit of information, so if it were added it seems that modules who claim to belong to a patch need to be listed
some how on the about screen even if in another tab other than the main screen. Perhaps a Version tab is needed in the
About screen which updates its model every time the user visits it and discards its model data when the user closes it. 

Anyways, those are my first thoughts on it. I haven't thought completely through the part where NB is a set of modules
and not really a patch based system, but I still go back to maybe it is just a user education thing, but then the
question comes up about manageability. Even with the patches idea there are manageability issues. You could have some
modules claiming to be part of Patch X yet not have all of them installed. 

Though I guess if there was an idea for a Patch in general then those modules could be grouped and displayed together
and the user can make what ever determinations they need, and it would be best to just show that the IDE installation
includes Patch X even if a few are installed with a blurb about needing to look in Tools|Plugins to make sure the entire
Patch is installed. Anyways, it is a tough notion because the idea of a patch would mean some new ideas would have to be
added to the base, and instead of throwing it together it would be best to make sure the design was at least 90%
something good and workable (100%s are hard to come by when speaking of design :-D)
Comment 2 pgebauer 2008-01-03 13:58:02 UTC
The best and easiest way how to check whether patches for modules have been applied or not is 'Updated' tab in Plugin
manager. If a patched module has been un-installed (or if a module has not been installed yet) user do not need to care
about a patch for that particular module.

In fact, there is no 'Patch 1' as a whole in Netbeans. There are 'only' updates for plugins. If user uses a plugin he
will be able update it (if any update exists). If user doesn't use a plugin he will not need to update it. If user wants
to add a plugin from available plugins he will get the newest one (it means patched one). There is no option how to get
old one from AUC.

So I do not see the reason to manually add spec. numbers in PatchesInfo page. This is less reliable than check via
'Updated' tab.

Things regarding grouping of updates into Patch X and its installation and mainly its un-installation should be taken
into consideration during future development but it cannot be solved by PatchesInfo page modification.
Comment 3 Karthikeyan Rajeswaran 2008-01-03 17:07:21 UTC
1. Regarding spec numbers in patchesinfo, following are the counter-arguments to the previous additional comments:
a. The purpose of PatchesInfo is to provide information about a patch, which IMHO means:
- What the patch does. (Bugs fixes in the patch).
- What the patch contains: A list of nbms and their spec number. The name alone does not identify an nbm; it is the
(modulename + spec number) that uniquely identifies an nbm.

b. > The best and easiest way how to check whether patches for modules have been applied
> or not is 'Updated' tab in Plugin
That is a good point; the best source for information on an object is always the object itself and duplication of
information should always be avoided if we wish to avoid problems with things going out of synch. But then, for
cross-checking purposes, identifying information about the object should be kept elsewhere. Otherwise we are required to
take things on trust (that there were no bugs while posting the nbms, that a patched nbm somehow didn't get replaced by
a different request to update center team etc). If we have the name+spec-number, that would be one way to check if the
update center indeed has what it is supposed to have. (I realise this is very easy to check for engineers; just go to
the codebase. But for users, it is not so easy to check now..)

2. Grouping
> Things regarding grouping of updates into Patch X and its installation and mainly its un-installation should be taken
> into consideration during future development
I agree; Wade has raised some interesting points. Even if it is decided not to fix the specific problem of specnumbers
in patchesinfo, this issue should itself, imho, be kept open until the suggestions are discussed (either here itself or
moved to another forum)
Comment 4 pgebauer 2008-01-03 21:09:19 UTC
The purpose of PatchesInfo is to inform a user about fixed bugs in a particular updated/patched plugin. This should help
him decide whether apply the updated/patched plugin or not. This should not be info about the patch with the meaning of
'What the patch contains: A list of nbms and their spec. number'. From NetBeans user point of view there isn't defined a
term 'patch' as set of updated plugins.

>for cross-checking purposes, identifying information about the object should be kept elsewhere
I agree, info for cross-checking is kept on internal places and it is used during testing on staging. But I don't see
how this info can help to a user to decide whether apply an updated/patched plugin or not. I do not expect that a user
will participate on that testing.

The only reason for introduction of spec. number for a plugin on PatchesInfo page could be situation when a plugin is
updated for the second time. The plugin version will be used in this case if needed.
Comment 5 Karthikeyan Rajeswaran 2008-01-16 22:44:29 UTC
See thread: http://www.netbeans.org/servlets/ReadMsg?list=nbusers&msgNo=108925
Comment 6 Karthikeyan Rajeswaran 2008-02-08 18:01:24 UTC
The spec numbers are now part of the PatchesInfo page; that issue by itself has been resolved.

Until the concerns raised by Wade are addressed, we will keep this issue open (reassigning the issue to myself).
Comment 7 rnovak 2009-01-09 16:14:36 UTC
ping - does it still need to be open ?
Comment 8 Karthikeyan Rajeswaran 2009-01-11 20:41:34 UTC
The module version numbers of patched modules are now made available in patches info page.
Ex: http://wiki.netbeans.org/NetBeans6.5PatchesInfo
This provides one way for users to check whether the version they have is the latest patch version.

Let us go ahead and close this bug.