| Hi David,
could you please clarify why exactly updates would be needed from projects because of changes to Orbit bundles? Does it result from the fact that Orbit bundles are actually re-bundled by project features? Or from the fact that requirements on them are specified too restrictive within project bundles or features?
I’m not sure if this is already covered by some simrel reports, but IMHO we would be pretty safe if we ensured that
1) no Orbit bundles were actually re-bundled in project features, but only required by them, and that 2) dependencies on Orbit bundles or packages would be specified in line with the respective Orbit main releases (based on proper version ranges),
because the aggregation could then pretty much control which Orbit bundles get pulled in. If we would in addition impose the same restrictions on Orbit releases as on project releases (namely that updates including breaking changes are not allowed in maintenance releases), I would assume no project should actually have to update its contribution for a maintenance release.
Cheers Alexander
HI
"commons.collections" doesn't seem
that well used. No version of it is my workspaces, so QVTd,
(Xtext, EGIT, UML, QVTo, OCL) cannot have a dependency on it. No
re-contribution needed.
Regards
Ed Willink
On 04/02/2016 20:19, David M Williams
wrote:
Ed,
Thanks for bringing this "no
maintenance,
no new Orbit" issue to my attention.
While the Planning Council does
not
like to "make" people do extra work they would not normally do,
I believe it was the intent of one of our requirements [1] that
the latest
Orbit be consumed every update release -- if there has been a
new Orbit
"released". Most often there is not a new Orbit release, since
we in Orbit do that only for significant issues. This time, it
was only
for the 'commons.collections' security bug, and a bad bug in Ant
1.9.4
that drove us to provide Ant 1.9.6. [2].
While I will not say you *have*
to update
and provide a new build, I would encourage you to, as well as
anyone else
who uses "commons.collections" since we don't want to "spread
around" a package that has known security flaw in it.
As far as I know, in most cases
of installing
and updating people will get the correct, fixed version of that
bundle,
but am not positive that is always true so I hate for it to be
the available
from any of our "most recent repositories" (Simultaneous Release
or not) -- after all, the b3 aggegator is including it for some
reason
-- so someone must say they require it?
But I am also not the "security
policeman" that will say that bundle must be expunged from all
current
downloads. (If I recall, the security issue only applied to
specialized
cases ... but, if you were running in that case, it was a bad
security
bug possibly leading to a malicious person "executing arbitrary
commands".
I have opened bug 487285 to
investigate
or discuss this issue further. [3] And, I will put this on
future
Planning Council agendas to see if we can word that requirement
[1] better
so that all projects know better what is expected of them.
Thanks again,
[1] https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Re-use_and_share_common_third_party_code_.28partially_tested.29
[2] https://dev.eclipse.org/mhonarc/lists/orbit-dev/msg04419.html
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=487285
From:
Ed Willink
<ed@xxxxxxxxxxxxx>
To:
cross-project-issues-dev@xxxxxxxxxxx,
Date:
02/04/2016 01:12 AM
Subject:
Re:
[cross-project-issues-dev]
Ready for Mars.2 ?
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
Hi David
On 03/02/2016 22:29, David M Williams wrote:
- Every contribution file has
changed
since Mars.1. Also good. (i.e. no projects are just sleeping and
forgot
to update :)
You might want to review your query. qvtd.b3aggrcon
was
last changed by me on 26 June, and by you on 14 July.
We are certainly not sleeping, and did not forget to update.
Just working
very hard to support the functionality required for graduation
to 1.0.0.
And ... worst of all, IMHO, some
"old"
third party jars are still being used, which implies to me
someone is not
using the latest version of Orbit (R20151221205849).
But if a project has no maintenance to contribute,
I thought
no rebuild/contribution was required and so of course an old
Orbit would
be in use. (I don't think that QVTd imposes tight bounds on
Orbit contributions.)
Regards
Ed Willink_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
-- Dr. Alexander Nyßen Dipl.-Inform. Principal Engineer Telefon: +49 (0) 231 / 98 60-202 Telefax: +49 (0) 231 / 98 60-211 Mobil: +49 (0) 151 / 17396743 http://www.itemis.de alexander.nyssen@xxxxxxxxx itemis AG Am Brambusch 15-24 44536 Lünen Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
|
