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.
Summary: | changes in osgi bundles aren't always provided for download from UC | ||
---|---|---|---|
Product: | platform | Reporter: | Tomas Stupka <tstupka> |
Component: | Autoupdate | Assignee: | Libor Fischmeistr <lfischmeistr> |
Status: | REOPENED --- | ||
Severity: | normal | CC: | jglick, jtulach |
Priority: | P2 | Keywords: | API |
Version: | 7.2 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
Tomas Stupka
2012-03-28 13:33:40 UTC
As far as #2 goes, I'd suggest to use the OSGi text after 3rd dot (which can be any text) as a 4th number (if it is a number). Autoupdate would just have to pay attention to it and use it if available. Whenever we would like to publish a patch, we'd specify (or increment) the 4th digit. #1 applies to any module; AU does not support downgrading. For #2, I doubt anything special needs to happen in infrastructure: diff --git a/javax.xml.soap/build.xml b/javax.xml.soap/build.xml --- a/javax.xml.soap/build.xml +++ b/javax.xml.soap/build.xml @@ -6,7 +6,7 @@ <zipfileset src="external/saaj-1.2.0.jar"/> <manifest> <attribute name="Bundle-SymbolicName" value="javax.xml.soap"/> - <attribute name="Bundle-Version" value="1.2.0"/> + <attribute name="Bundle-Version" value="1.2.0.1"/> <attribute name="Export-Package" value="javax.xml.soap;version="1.2.0""/> <attribute name="Import-Package" value="org.w3c.dom"/> </manifest> or am I missing something? (In reply to comment #2) > #1 applies to any module; AU does not support downgrading. with an external library provided via external/binaries-list you replace the binary in the list with an older version and raise the nb module version. This isn't posible in case of an osgi bundle. (In reply to comment #3) > (In reply to comment #2) > > #1 applies to any module; AU does not support downgrading. > with an external library provided via external/binaries-list you replace the > binary in the list with an older version and raise the nb module version. This > isn't posible in case of an osgi bundle. Is it still a problem? I don't know what I should fix there. (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > #1 applies to any module; AU does not support downgrading. > > with an external library provided via external/binaries-list you replace the > > binary in the list with an older version and raise the nb module version. This > > isn't posible in case of an osgi bundle. > > Is it still a problem? I don't know what I should fix there. it will be in problem once we will have to place on the UC a lower version as there already is. With other words - we have no way how to replace (downgrade)) e.g. a regressing library We don't have a way to downgrade NetBeans modules either. We can only provide newer updates. There is no reason to request downgrades from OSGi bundles. Just fix what is necessary and release an update. When there is a fix in an OSGi bundle and it does not change its specification version, we should have a way to deliver it to users. As Jesse suggested, using fourth digit might do the trick. When in total despair, you could potentially downgrade from 1.2 to 1.1 and just call the old version "1.2.0.1-downgraded-to-1.1", imho. |