[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cross-project-issues-dev] M6 in danger
- From: Thomas Hallgren <thomas@xxxxxxx>
- Date: Wed, 12 Mar 2014 08:55:06 +0100
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
On 2014-03-12 07:50, Eike Stepper wrote:
That's an odd statement to make given that there hasn't been any release of Luna yet! The last release of Eclipse is
indeed Kepler SR2 and Buckminster is built on that.
I just found the cause of the problem and could work around it. Please expect my M6 build early today. Because of the
API breakage in EMF Compare it might be necessary to coordinate my contribution with Laurent. I already pinged him
The original problem is very odd, though, and my work-around is not a permanent solution. Here's the short summary:
Buckminster is always one release behind ;-(
Please don't write statements that blame Buckminster and ends with an unhappy face unless the blame is well deserved. In
this case it isn't. We never made any promises regarding tail-chasing milestone builds of the release train.
For example when we build for Luna there's only a Kepler Buckminster available and that "works best" with a Kepler
That would still be acceptable but:
A) Our build also uses two self-made tools for extended version management and API report generation. These tools are
installed from our own integration p2 repository which was built previously against Luna.
B) This (our) p2 repo also contains a p2 feature. Not that I'm happy about that, but we build p2-based products and with
a feature-based product build I see no way to exclude these dependencies from our own repo.
In effect my Buckminster installation "sees" p2 in three different locations:
1) The Buckminster headless repo (4.3)
2) The Platform repo (must be 4.3, because there's no Bucky 4.4)
3) Our own repo (here we have a p2 4.4!!!)
I wish you'd mention this when you first reported the problem. That would have saved me some sleep.
Tail-chasing the release train is time consuming and not something that we currently have resources for. Someone must
step up to the task for that to happen.
My current work-around is to disable all our own tools during the build (and not install them), so that the Buckminster
installation can use only Kepler repos.
I'm not sure if anyone could follow til here but I see two options for the future:
1) I continue NOT to use my own tools in my build (although Ed and I have spent weeks to develop them).
2) Buckminster starts to produce builds for the CURRENT release train (whether contributed to it or not).
Needless to say that I favor option 2, but maybe someone else sees more options?
Our current approach has been to publish a milestone build of Buckminster shortly after the last milestone has been
published and then release shortly after the official release-train release in June.