[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-dev] Should .settings/ participate in version qualifier or not?
|
Hi MickaelI've spent some
time thinking about this. Actually, when not including .settings, a warning
about changes in binaries without source change would be good as it gives
a hint to actually increase the version. This comes in addition to Sravan's
arguments.So, +1 from me
to exclude .settings. Please proceed.DaniFrom:
"Sravan
K Lakkimsetti" <sravankumarl@xxxxxxxxxx>To:
"Eclipse
platform general developers list." <platform-dev@xxxxxxxxxxx>Date:
21.06.2019
07:05Subject:
[EXTERNAL]
Re: [platform-dev] Should .settings/ participate in version qualifier
or not?Sent
by: platform-dev-bounces@xxxxxxxxxxx
Hi,
I
am inclined to say no unless preferences from .settings are used in the
our build. Right now we don’t use any of these preferences in our regular
builds. Also we don’t include these in source bundles. I would say .settings
needs to be considered only when these preferences are used in the maven
build. Currently we don’t have any plugin that uses preferences from .settings
during maven build(they may be using these settings for eclipse build but
that is for developer’s use).
Thanks
Sravan
From:Mickael Istria <mistria@xxxxxxxxxx>
Sent: Thursday, June 20, 2019 6:11 PM
To: Eclipse platform general developers list. <platform-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] [platform-dev] Should .settings/ participate in
version qualifier or not?
Hi
all,
In
some other thread, you saw that some changes I've put in parent pom that
-amont others- excluded the .settings/ from qualifier computation.
While
I expected no trouble, this actually and unfortunately caused some issues,
so it was noticed and is discussed (while in some other more lucky circumstances
in which no bundle had a .settings/ change as last change, it wouldn't
have been noticed and there would be no debate and things would be settled)
and the change was reverted.
This
change per se is not related to other bugs about API Tools, we managed
to separate both issues, so let's now get back to the mailing-list rather
than polluting API Tools bugs.
I'd
like to gather opinions about "Should .settings/ participate in version
qualifier or not?".
The
current state is yes. When one change any project settings (resulting as
some .settings/blah.prefs file change), the bundle version needs to be
bumped if it was not already, otherwise a failure would be reported because
of"qualifier-only version increase compared to last release (which
is not allowed for bundles). However, in many cases, those changes don't
affect the build output as they're change for inside the IDE, not real
build control. In such cases, versions are bumped without a change in the
build output.
If
we ignore the .settings/ , then we don't have the need to bump version
on such changes, and we can update project settings while reusing and reshipping
the "current" baseline version of the artifact, as long as it's
binary equivalent. We have some checks in Gerrit and main build to ensure
binary equivalence when versions are identical. The only possible drawback
is that some preferences in .settings/ can affect binary output, so by
not bumping versions, we may see some failure or report of error during
the various builds. Also the cost is that ironically for all bundles that
have a .settings/ change as their last commit, it would require to bump
their versions once.
To
me, the later proposal is better as it can participate to the reduction
of produced versions (less artifact versions == less QE in theory, smaller
download size for upgrades, optimized disk space on some filesystems...),
and I think the risk of changing .settings/ that affect the build output
is 1. minor and 2. already under control by the binary version comparison
check.
What
would be your opinion on this one?
--
Mickael
Istria
Eclipse
IDE developer,
for Red
Hat Developers
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev