|[cross-project-issues-dev] Component release hiding (was Re: [Brainstorming] Why (not) a "Final Daze" in SimRel?)|
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
ÂÂÂ ÂÂÂ Ed Willink
On 28/06/2017 06:10, Mickael Istria wrote: