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 231766

Summary: Pluginportal needs upload option for _each_ released version
Product: updatecenters Reporter: matthias42
Component: PluginportalAssignee: Jiri Kovalsky <jkovalsky>
Severity: normal    
Priority: P3    
Version: 7.3.1   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:
Bug Depends on: 226906    
Bug Blocks:    

Description matthias42 2013-06-25 10:18:49 UTC
The interim release of 7.3.1 breaks my plugin:

The plugin needs an implementation dependency on the issue tracker module (there is no exposed API/SPI). The 7.3.1 update changed the implementation version, so currently I can choose whether to support 7.3 _or_ 7.3.1, but not both.

The first user noticed that and I'm not happy with this. Last time (7.2 -> 7.2.1) it broke the same way and a new build of the issue tracker module was pushed via the update centers, but I don't want to ask on each release, that compatibility should be provided.
Comment 1 Jiri Kovalsky 2013-06-25 10:33:15 UTC
Can't you really change the hard dependency from

OpenIDE-Module-Module-Dependencies="org.netbeans.modules.bugtracking = 201302132200

to something like

OpenIDE-Module-Module-Dependencies="org.netbeans.modules.bugtracking > 1.58


BTW, we already want to disable verification requests for plugins with hard dependencies in RFE #226909.
Comment 2 matthias42 2013-06-25 10:54:36 UTC
Disabling verification just makes it worse. I discussed this last year and no netbeans dev could tell me a valid solution (apart from fixing bug 162279).

I know the difference between an implementation dependency and a specification dependency. But the issue tracker modules exports its api friend-only.

Big question: Why aren't _all_ the changes from 7.3.1 just pushed as an auto update to 7.3 (nbusers showed some discussions in that direction). I would upload a rebuild version of the plugin - now against the common new implementation version and be done with that.
Comment 3 matthias42 2013-06-25 18:37:55 UTC
Considering bug 226906 - which is the exact oposite I would like to see, this is a won't fix, so keeping this open is point-less.

Closing as described.