[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cbi-dev] tycho and qualifiers
|
> 2. Compare build results to a baseline build ignoring version qualifier.
> If build results did not change, use build results from the
> baseline build.
I think one issue is that the results pretty much always change. At least
in some way, at least when looked at "byte by byte", so the issue becomes
"how to compare" and "what changes are meaningful". And ... even then ...
which of those changes desired to be "picked up" as most recent or
considered important for which projects?
I'm sure all those are answerable and solvable, but, complicated. Not that
I would know (was not part of decision making) but I think that's why
(partially) PDE build in past "took you at your word" if the qualifier
changed that is indeed what was desired, but then do a quality check that
if qualifiers did not change, to confirm the bundles did not change in some
meaningful way that would call for a deliberate qualifier chagne.
Some small examples of how bundles "always change". Many have an
"about.mappings" file that explicitly, purposely lists the "date of
build" (which if that is only change, is not significant). Another
example, the signing at Eclipse uses the "Time Stamp Authority" to insert
some data that is essentially "signed on <this date>" (so it can be
determined if cert valid when signed, even if cert is later out of date).
There are many other, smaller ways, I'm sure, that some projects purposely
decide "not significant enough" to justify a new qualifier. Even for
changes in Java byte codes ... sometimes, the JDT compiler improves so it
does a better job of leaving out "dead code". Well, sure, its nice to
update the bundle to "latest compiled" but, technically there is no reason
it has to, and I could imagine cases where someone might be most concerned
about absolutely minimizing downloads for updates or maintenance so
wouldn't want qualifier to change merely because dead byte codes were
removed, that the project might need more substantial reason to.
Another rub, some projects, I think pretty much purposely always change
qualifier as a matter of principle (that, they consider it "safer" and
easier to maintain and investigate bugs from the field). I can't speak for
EMF now, but I think years ago (last I heard it discussed) they were taking
that position. That is was safer to always change, partially because they
"compute" their manifest.mf file based on current pre-reqs, even if nothing
else changes. Sapphire does a similar thing and buckminster builds too I
think (but each of those use more complicated algorithms for computing
minimum pre-req range, not necessarily just "what built against"). Point
is, currently, different projects have different policies to updating
qualifiers, that they have considered important to them and their
maintenance efforts.
Again ... all solvable, I'm sure, but a) seems complicated, and b) seems
different projects would prefer to have different policies they could
specify, not a "one size fits all" approach.
I mean all this note this only as "data" ... not trying to poo-poo your
ideas. There is some merit to them, but wouldn't want to "hard code" too
much :)
In another note, you asked
> What is the usecase for using different version qualifiers for different
> projects from the same git repository?
(apologies if already answered) but I think the reason is simple: at
eclipse, for better or worse, right or wrong, some git repositories have
LOTS of bundles in them. Some bundles might not change at all, for years,
others would change every release, every service release, and maybe even
milestone and many I-builds. I think some would a) find it overkill to
either change all their qualifiers based on one bundle changing, and b)
find it tedious to have very fine-grained repositories (such as one per
bundle, or one per 3 or 5 tightly coupled bundles) ... but, again ... there
could be some balance where the "qualifier heuristic" drives the repository
make up ... but, seems kind of a stretch.
I hope these answers help provide some history and insight .. they are
definitely not meant to argue against attempts to improve current state of
affairs.
Thanks,
From: Igor Fedorenko <igor@xxxxxxxxxxxxxx>
To: cbi-dev@xxxxxxxxxxx,
Date: 02/11/2012 08:01 AM
Subject: Re: [cbi-dev] tycho and qualifiers
Sent by: cbi-dev-bounces@xxxxxxxxxxx
Build configuration can be inherited from a parent pom, so build output
can change even if the files under project basedir did not. Using pde.ui
as an example, one can specify jsr14 compile target in
eclipse.pde.ui/pom.xml and this will affect all pde.ui bundles.
This is why I suggest using two-phase approach for generating build
versions
1. Generate build qualifier using tagged commit.
2. Compare build results to a baseline build ignoring version qualifier.
If build results did not change, use build results from the
baseline build.
--
Regards,
Igor
On 12-02-10 11:13 AM, Paul Webster wrote:
> On Fri, Feb 10, 2012 at 10:36 AM, Igor Fedorenko <igor@xxxxxxxxxxxxxx
> <mailto:igor@xxxxxxxxxxxxxx>> wrote:
>
>
> What is the usecase for using different version qualifiers for
different
> projects from the same git repository?
>
>
> Our bundle qualifiers change when the code changes. For example.
> eclipse.platform.ui has 92 bundles and most of them haven't changed
> since 3.7. Their qualifiers shouldn't change either.
>
> Git is happy to provide the last commit to touch a subdirectory and
> that's what we're currently using to generate a qualifier for each
> bundle, which we are using as part of the standard PDE build/map file
> process.
>
> We are in a partial state right now, which is changing bundles have the
> new v<UTCtimestamp> qualifier that's tied to the last commit to touch
> that bundle. Bundles that haven't changed are using the tag from the
> map file, and that works for us currently because of the Git PDE fetch
> factory copies each bundle out of its git repo. One of our options for
> 3.8/4.2 is to switch all of the bundle qualifiers to the new format ...
> take some churn now for some stability going forward.
>
> Or are you asking about our build input? It's always been our intent to
> supply one commit as the build input (our auto-tagging works from our
> integration or master branch, and I believe it's consistent with the LTS
> prototype being an aggregate repo that specifies the other repos as
> submodules).
>
> Later,
> PW
>
> --
> Paul Webster
> Hi floor. Make me a sammich! - GIR
>
>
> _______________________________________________
> cbi-dev mailing list
> cbi-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cbi-dev
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cbi-dev
