[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Fwd: Change 73676 insimrel/org.eclipse.simrel.build[master]: Update PTP to RC2

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
My blog - My Tweets


_______________________________________________
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