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.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
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
_______________________________________________
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
