Yes. Builds should fail when they are wrong, not while misguided
administration policies play catch-up.
We have perhaps 30 projects that depend on EMF.
- each project specifies a precise 4-part EMF version dependency
- EMF deletes all old versions before creating a new contribution
Then every time EMF re-contributes, the aggregator will fail until
all 30 projects have caught up. In the meantime another popular
dependency such as GEF may cause further grief.
Fortunately we avoid the above scenario because
- EMF is well-behaved and retains repositories for a reasonable
- EMF's consumers trust that EMF will be well-behaved API-wise and
so have a weaker than 4-part dependency
Just imagine a 4-part dependency on the platform, and perish the
thought that the platform might respin with an "a" contribution...
On 26/05/2016 09:31, Mickael Istria
On 05/26/2016 10:23 AM, Ed Willink wrote:
A build failing because of content moving unexpectedly or being
simply wrong is actually a good thing. The goal of automated
builds isn't to always be successful, it's also (and maybe mainly)
to catch issues or bad smells whenever they happen.
Contrariwise, surely this is a classic example of why precise
feature bounds are bad?
Let's consider such failed builds as a way to keep and raise
maintainability and quality of SimRel.
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit