Bug 19714 - Implement "windowed" major release version dependencies
Implement "windowed" major release version dependencies
Product: platform
Classification: Unclassified
Component: Module System
PC Linux
: P2 (vote)
Assigned To: Jesse Glick
Depends on:
Blocks: 17773
  Show dependency treegraph
Reported: 2002-01-24 12:21 UTC by Jesse Glick
Modified: 2008-12-23 13:45 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2002-01-24 12:21:17 UTC
Sometimes it happens that a library module A/1 1.1 has two subcomponents
(packages say), Ax and Ay, but they are together in one module. Module B depends
on A/1 > 1.1 and uses Ax, but does not care about Ay. Now it is decided to
refactor Ay into an incompatible and different Ay2, so A/2 2.0 is released with
Ax and Ay2. Technically A is now incompatible, hence to move to the A/2 major
release. However module B needs to change its declaration to A/2 > 2.0 even
though it is not affected by the change at all and could work just as well with A/1.

So feature: permit B to declare in its manifest:

OpenIDE-Module-Module-Dependencies: A/1-2 > 1.1

(syntax look natural?)

which will be satisfied by module A if either:

1. It is major version 1, and the spec vers is >= 1.1.

2. It is major version 2 or higher (any spec vers).

Usage style: B would initially have the normal dependency on A/1 > 1.1. When A
is refactored into A/2 2.0, and the developer of B examines the changes and is
satisfied that the refactoring did not incompatibly affect the portion B uses
(Ax), the developer of B may change its dependency to A/1-2 > 1.1 and release a
new version of B with this dependency update. This ensures that the same version
of B will work with appropriate existing versions of A/1, as well as with any
version of A/2 (it must be kept compatible after 2.0 of course, so this is
known). It is possible that a further future refactoring into A/3 could break
the Ax package, so the dependency does not make any claims about B's
compatibility or incompatibility with the hypothetical A/3.

Generally then a module dependency may be of the newly added forms



X/j-k > m.n.o

(no implementation version comparison permitted in this style!)

Where X is a valid module code name base; j and k are integers, 0 <= j < k;
m.n.o is a valid specification version.

The first matches any version of X whose major release version is between j
(inclusive) and k (inclusive). The second matches any version of X whose major
release version is j and whose specification version is greater than or equal to
m.n.o; as well as any version whose major release version is between j
(exclusive) and k (inclusive), whatever the specification version.

Conventionally, to minimize confusion, specification versions should always go
up and not down when raising the major release version, but technically a higher
major release version always indicates a newer module, regardless of the
specification version.

Impact on APIs other than permitting the new kind of dependency: minor
implementation change in org.openide.modules.Dependency parsing code.
Comment 1 Jesse Glick 2002-01-24 12:25:12 UTC
Will use module_deps_jan_2002 branch for implementation: branching
core openide nbbuild apisupport, so far.
Comment 2 Jesse Glick 2002-01-28 12:29:22 UTC
Work complete in branch, incl. tests; pending merge.
Comment 4 Jan Zajicek 2002-03-22 10:59:46 UTC
verified in nb 3.4 builds (used aut. tests from Jesse)

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