[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[buckminster-dev] Extended version management in 0.2.0
|
The post Europa development has started and one of the major changes
that we plan for the 0.2.0 release concerns a general cleanup in the way
we use versions, branches, tags, etc. in the resolution.
Recap:
We support two distinct resolution strategies:
1. The direct case.
We use component versions directly when we scan a repository that is
based on versions (like the Maven repository). We also use this method
when we read the trunk, head, or latest of a Source Code Control (SCC)
repo. In short, this strategy can be explained by stating "We look at
the version found in the component meta-data".
2. The converter case
The component version is converted into a branch or tag that is then
understood by a SCC repo. The strategy explanation is: "We consider the
tag or branch of the found component to be its version and disregard any
version information found in its meta-data".
Planned improvements:
We will introduce space names and a space path where a space is a
"naming authority" such as "maven.org" or "eclipse.org". We have also
been discussing a "branch path" that would help us express things like
"First look if there is a 3.2.x branch of this component. If not, look
in the trunk" (this particular case would have been very useful to us
right now). I would like to extend this path so that it could contain
both branches and tags.
Last but not least, we would also like to look at specific revision
numbers or timestamps (we can do this today, sort of, but it's not very
intuitive). I think this is separate from branches and tags since it is
very valid to say "give me revision 1243 of branch foobar". I have yet
to see a use-case where you request a certain tag from a specific
branch. Eclipse CVS implementation does not support such a combination
and in SVN it is a contradiction in terms.
I have tried to boil this down to something that is simple to understand
by making the following statements:
* The version designator origins from a component request. The
designator is always completely free from all concerns regarding
branches, tags, timestamps, revisions, and space paths. It will
typically specify a range of OSGi or Triplet versions.
* The component query advisor node may specify the following:
- an override for the version designator (we have this already)
- a path consisting of branches and tags
- a space path
- a revision number or a timestamp (mutually exclusive)
* A repository provider may specify:
- a version converter (to support the converter case, this is there
already)
- a space name
- a branch or tag name (to be used as discriminator)
* If a repository provider defines a version converter, it will use the
"converter case" (#2 above) when resolving. The tag/branch path will
still be used for discrimination so a version converted into a branch
that is not included in the path will not be found.
* Since several criteria are used, we need to prioritize when selecting
the best match. I suggest the following priorities (in descending order):
- version designator
- lowest ordinal in tag/branch path (i.e. where in the path the match
occurred)
- lowest ordinal in space path
I didn't list the revision number/timestamp since they can be considered
an absolute constraint.
Example:
My tag/branch path denotes the branches X, Y, and Z
My version designator says [1.0.0,2.0.0)
My space path says org.maven, org.eclipse
We assume that the resolution service finds the following:
1.2.3 in branch Y in space org.eclipse
1.2.3 in branch Y in org.maven
1.2.4 in branch X in org.maven
1.2.4 in branch Y in org.maven
1.3.0 in branch Z in org.eclipse
Given the above priorities, it would be sorted (descending) like this:
1.3.0 in branch Z in org.eclipse (version designator has highest prio)
1.2.4 in branch X in org.maven (ordinal of tag/branch path is lower)
1.2.4 in branch Y in org.maven
1.2.3 in branch Y in org.maven (ordinal of space path is lower)
1.2.3 in branch Y in space org.eclipse
and hence the 1.3.0 version would be chosen.
Comments? What did I miss?
- thomas
