Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Heads up for early Juno M6 aggregation breakage due to dependencies on "Indigo Platform"

Well, good point, and maybe that's how these other projects do it ... and
its successfulness I guess depends on how good your tests are ... but, if
it was me I'd try building against Indigo specifically, and then building
against Juno specifically to make sure there were no compile time breakages
(even if, you then "threw away" one of those builds, and shipped only one).
I have heard some people do one build but use "API Tests" to do a similar
sort of check of compatibility for other versions, but I know less about
that specifically.

In the types of cases I mentioned, such as if a bundle depended on
org.mortbay.jetty.server, then a build (or, test, I'd think) would fail on
Juno and but succeed on Indigo and would require some type of change
(perhaps different streams, or perhaps just a change of "packaging").

But, your process and desire to be compatible with previous version
certainly has its merits, and we would not have been helping people's
testing efforts by having /releases/juno pointing to old stuff. So, perhaps
that's prevented people from seeing the issue in their tests?

Thanks for that bit of education :)





From:	Igor Fedorenko <ifedorenko@xxxxxxxxxxxx>
To:	cross-project-issues-dev@xxxxxxxxxxx,
Date:	02/02/2012 04:06 PM
Subject:	Re: [cross-project-issues-dev] Heads up for early Juno M6
            aggregation breakage due to dependencies on "Indigo Platform"
Sent by:	cross-project-issues-dev-bounces@xxxxxxxxxxx



I am not sure I understand what you recommend. Using m2e as an example.
Our goal is to maintain compatibility with at least one previous Eclipse
release. The version we ship with Juno is expected to install and wort
on Indigo. So we build m2e against Indigo and then test with both Indigo
and Juno. Is this good enough approach or should be do something
different to make sure we don't cause problems?

--
Regards,
Igor

On 12-02-02 3:49 PM, David M Williams wrote:
>
>
> M5 is not even out the door and problems already known about M6
> aggregation! ... how's that for early warning? :)
>
> See bug 370405 [1] for details (and feel free to comment there) but by a
> series of bugs, coincidence, and my own missteps, our Juno aggregation
> repository still "points to" an old Indigo Platform repository as well.
>
> Obviously that's wrong and I thought it would be a simply thing to remove
> it for M6, but from what I can tell (testing locally) it will not be so
> simple. Apparently some are still depend on some "old" bundles that just
> happened to be in the Indigo Platform, but are no longer in the Juno
> Platform.
>
> For example, if my local tests are correct,
> BIRT, depends on org.apache.jasper
> org.eclipse.mtj.core depends on org.mortbay.jetty.server
>
> There could be many others .... those are the initial ones that seemed to
> be causing issues, when I was "testing locally" but once those are fixed,
> then others might show up.
>
> So, here's the plan and my requests:
>
> I plan to make the fix to remove the old repo from aggregation build as
> soon as M5 is done, and this may cause some quick breakages. (I will
> restart the aggregation builds on Friday, 2/3). If your project's
> aggregation breaks due to this Indigo platform no longer being there,
then
> I would request you get a fix in quickly during M6 (within a few days)
and
> not wait until your +n day. The reason being is that once your fix is in,
> then other dependency issues might show up, and might take a while to
track
> down and fix them all.
>
> To make a fix, if you need one, you have two options: 1) move up to
latest
> pre-reqs that are in Juno Platform (most preferred, probably) or 2) you
> need to "package up and ship in your own repo" the old bundles yourself.
>
> My last request, if your project does have one of these "depending on old
> platform pre-reqs" issues, I'd ask you take a step back and figure out
how
> your own Juno build kept working. I always encourage people to build
> against a very specific target, since that's the only way to know your
code
> is correct for the current prereqs. Also, I have also always recommended
> people contributing to Juno repo should not build against Juno repo,
since
> that is what is being developed and a) could be wrong or b) not current
> enough.  Or, there could be other explanations that I am not aware of. It
> just seems odd to me that a "build for Juno" would unknowingly have
prereqs
> from Indigo Platform. So, I am just asking you to examine your processes
> and consider improving your builds to be more specific (or, I would
> appreciate you educating me ... just out of my curiosity ... on how it
has
> nothing to do with your build procedures).
>
> Thanks as always,
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=370405
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev





Back to the top