Hi
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.
If
- 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
interval
- 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...
Regards
Ed Willink
On 26/05/2016 09:31, Mickael Istria
wrote:
Hi,
On 05/26/2016 10:23 AM, Ed Willink wrote:
Contrariwise, surely this is a classic example of why precise
feature bounds are bad?
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.
Let's consider such failed builds as a way to keep and raise
maintainability and quality of SimRel.
_______________________________________________
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
