Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Re: Versioning tools for download and evaluation (Eclipse Build Workshop)


>1. Why is only the qualifier considered when calculating the suffix and not the version string as a whole?
>2. Why are only those features that has a suffix included? And why the
suffix only?

        The qualifier mechanism has been introduced to support I-build to I-build increase of version numbers. Other changes should be captured manually by an increase of the version number of the feature or retagging of the feature itself. That said we have had problems with this scheme and are thinking of considering all the segments in the computation of the qualifier for features.

>1. Assume I have a feature that have some root files to be copied to the
product root. I change some file and I also change the timestamp part of
the qualifier. The set of included features/plugins stays exactly the
same. If I've understood it correctly, this means that the suffix
generation will produce the exact same result.

        Nope. The qualifier of the feature will change since the timestamp is always used as a prefix to the generated qualifier. For example the the SDK feature version is org.eclipse.sdk_3.3.0.v20060815-omYoxj8JUrxM5Fs where v20060815 is the timestamp and the rest is the sum.

>The suffix generation of a feature that references my feature will thus miss the fact that the timestamp has changed.
        Yes and this is normal. If I push your example further, it would mean that when the RCP feature change, all the products from the world should be changed too. If you want the other feature to see the change it would have to include the feature and not require it. This is consistent with the semantics given to features by update manager.

>2. In an ever expanding world of features and bundles, it is not too far
fetched to assume that I'll include other features and bundles that I
have no control over and that follow some slightly different version
scheme. The current constraints on the input to the calculation will
prevent such a mix from using generated suffixes.

  This is why we put together recommendations on how to version plug-ins so that we are all aligned ;-)
  I'm not sure I clearly understand your worry. To me this is the same problem than when a plugin that you author changed its version number: the features including it have to rev their version too.

In any event, nothing is cast in stone and any concrete problem can be addressed as long as they are detailed in a bug report against PDE/Build.
I think we should move the rest of this discussion to the pde-build-dev mailing list.

PaScaL




Thomas Hallgren <thomas@xxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

10/15/2006 02:57 PM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject
[cross-project-issues-dev] Re: Versioning tools for download and        evaluation (Eclipse Build Workshop)





Hi Pascal,
Thanks for your reply and the pointers. It's always helpful to have
something to use as the starting point in the code. I've been looking
further at how qualifiers are replaced during building and I have some
questions.

When the genereatedVersionSuffix is turned on, the documentation claims
that the qualifier suffix is a 'sum' of the version qualifiers of
included features and plugins. When looking at the code
(FeatureBuildScriptGenerator.generateFeatureVersionSuffix) that appears
to be true for all plugins but only for feature references that in turn
also have a suffix and it appears that only the suffix from those
references takes part in the calculation and not the qualifier as a whole.

My questions are:
1. Why is only the qualifier considered when calculating the suffix and
not the version string as a whole?
2. Why are only those features that has a suffix included? And why the
suffix only?

I somehow suspect that the answer will be that the whole calculation is
attempting to detect plugin-changes and that those will ripple up
through the suffixes when features reference other features and perhaps
I'm missing the obvious but I have some concerns with this approach:

1. Assume I have a feature that have some root files to be copied to the
product root. I change some file and I also change the timestamp part of
the qualifier. The set of included features/plugins stays exactly the
same. If I've understood it correctly, this means that the suffix
generation will produce the exact same result. The suffix generation of
a feature that references my feature will thus miss the fact that the
timestamp has changed.

2. In an ever expanding world of features and bundles, it is not too far
fetched to assume that I'll include other features and bundles that I
have no control over and that follow some slightly different version
scheme. The current constraints on the input to the calculation will
prevent such a mix from using generated suffixes.

Kind Regards,
Thomas Hallgren

Pascal Rapicault wrote:
>
> The generation of qualifier is not bound to cvs. It is obtained from
> the "tag" found in the map file associated with the entry being built
> (the map file has supports for multiple repositories - see
> IFetchFactory and the associated extension point). If the value is not
> present, then we attempt to get it from the qualifier tag in the
> build.properties, and in the last case the value is generated.
> This replacement  of the qualifier is done when we are building the
> state of the target we are building (see PDEState.udpateVersionNumber())
>
> HTH
>
> PaScaL
>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Back to the top