[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cross-project-issues-dev] [eclipse.org-planning-council] Neon.3 Update Problems
- From: Ed Willink <ed@xxxxxxxxxxxxx>
- Date: Fri, 31 Mar 2017 08:32:16 +0100
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
Your comment is tooling dependent.
Unfortunately, in some cases specifying that XYZ requires a minimum
1.2.3 version gets converted by some builder into exactly 1.2.3 making
re-use across Eclipse releases impossible.
On 31/03/2017 07:22, Gunnar Wagenknecht wrote:
On 31. Mar 2017, at 05:38, David Williams <david_williams@xxxxxxx> wrote:
I think there is also another thing to consider. IMHO projects should stop hard-pinning specific 3rd party versions in the feature.xml -
This makes builds and installs non-deterministic.
I think our builds are non-deterministic now, i.e. there is no predictability what versions of a 3rd party bundle will be in a package and there is also zero predictability which Equinox will pick at runtime for resolving dependencies. Keep in mind that features are for assembling/installation but they have zero influence on the runtime resolution.
That's why I'm proposing to defer the decision, what gets put into a package, to the package build time. We test packages not individual projects.
Also, there are many projects that declare they require bundle XYZ with a minimum version of 1.2.3 in their dependencies. At the same time they also indicate that they are happy with any higher version. Thus, the argument that projects only run/support with a very specific version does not hold true. They may test with only one very specific version. They are - however - not very specific about that in their bundle dependency declaration.
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
This email has been checked for viruses by Avast antivirus software.