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!
_______________________________________________
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