Hi
A new thread to focus on the side issue: whether not-hiding is appropriate.
We seem to have three plausible release practices:
a) the hidden until released Final Daze policy - this seems very
important for project pairs that produce/consume a new API.
b) the early release policy - e.g. EMF, Xtext - fine when no significant
APIs change requiring precise versions
c) the independent release policy - e.g. EGIT - fine when genuinely
independent.
---
Early releases for a very stable +0/+1 component such as EMF may be
beneficial since does anyone really care whether they get the new
version? Well yes but only if some other component imposes an
undesirable tight upper version bound.
Early releases for a +2/+3 component such as Xtext may be beneficial but
it mandates that the release support both old and new SimRel APIs.
A late detected bug may require an early release to have a swift +0.0.1
to suit the new SimRel, and perhaps this needs hiding after all.
But is EMF very stable? EMF now has Xcore functionality that introduces
a cyclic dependency on Xtext whose very high degree of auto-generation
makes pedantic API preservation almost impossible. (Xtext 2.8 to 2.9 was
a breaking change that required a Neon and Neon++ release of OCL to
accommodate it.) It would seem that an early release of EMF and Xtext
and intervening components must be synchronized to ensure that Xcore works.
---
Is EGIT really independent? Surely any added value such as EGerrit must
be coordinated? Perhaps the high release rate ensures that a new API is
produced well before it is consumed.
---
Minor issue. I find it necessary to look at the *.aggrcon to know what
is the release/milestone EGIT version or whether the latest Xtext is
experimental or contributing. Shouldn't e.g. EGIT have a version change
correlating to Simrel? Shouldn't e.g. Xtext's latest version always be
contributing? Surely an experimental release should not be on master and
not be available for download as a next release?
---
My conclusion. The not-hiding practices seem like a good idea but fail
to avoid real hazards with concurrent introduction of new API
production/consumption.
Regards
Ed Willink
On 28/06/2017 06:10, Mickael Istria wrote:
Thanks for sharing this David, it's quite helpful!
On Tue, Jun 27, 2017 at 10:11 PM, David Williams
<[email protected] <mailto:[email protected]>> wrote:
In many cases, it will work fine if someone updates their
composites early, but not necessarily all cases. At least,
historically, there have been cases where a user will be told
"updates are available" but then when they try to apply them will
be told "those updates conflict" with something else they have
installed, and then given a list of (possibly confusing) choices
(such as, "remove web tools so that emf can be updated?" [to
paraphrase, and it is just a hypothetical example]). Perhaps,
these days, these mismatches would occur less often than in the
past but I suspect not completely and the more projects violated
the "Simultaneous" aspect of update sites the more likely users
would see issues. That is the core technical reason why there is a
Simultaneous Release in the first place.
I agree with you that recent changes in EPP package being made more
"modular" make this kind of issues less probable. I also agree that
this kind of p2 issues are still possible if users does a mix of
multiple p2 sources.
In such case of additional sources being added, we cannot control
what's added, so I don't think we're really in the scope of SimRel. Or
at least, that this user-story isn't really what we and users are
expecting of SimRel (SimRel is a big p2 repo which we know all content
work consistently one with the other, nothing more).
Another reason (again, historically) is more mechanical: If some
projects (especially large ones) were available for updates early
then potentially hundreds of thousands of "update downloads" would
be occurring at the same time the mirrors were trying to download
gigabits (from other projects) to get fully populated and they
would less able to do so. In other words, a network bottleneck:
downloads for updates would be slow since there were so few
mirrors, and mirrors could not get populated because there were so
many downloads. You can avoid this bottleneck by having bits in
place (so mirrors can get them) but to not update the composites
until the appointed day (so that users will not be doing mass
updates early).
Ok. Do you agree with Ed and I that having projects setting up the
mirror when they *release* (typically a few weeks before SimRel
release) would prevent this issue from happening?
I am glad when I see efforts made to improve the Sim Rel
processes, but I wanted to be sure you kept these factors in mind
as you did. These factors tend to be forgotten when they do not
occur -- and they have not occurred for many years (I believe)
because most projects follow the recommended procedures.
Yes, and thanks for sharing those.
It's a matter of trade-off between the responsibility of a project and
the responsibility of SimRel. I think it's also important to make the
scope of SimRel clear enough (for example "SimRel builds an aggregated
p2 repository of projects conforming to quality guidelines and tested
to work together in the same p2 repository") and to see what should
remain the responsibility of SimRel (build+test+release of the SimRel
repo), what should be the responsibility of individual project release
process (p2.mirrorsUrl in individual p2 repos, do not leak p2
repositories as touchpoints or other without informing users), and
what should be the responsibility of users (avoid mixing p2
repositories unless they feel like p2 experts)...
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
