| Re: [platform-dev] Should .settings/ participate in version qualifier or not? |
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> 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 |