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 <https://www.eclipse.org/downloads/eclipse-packages/> developer, for Red Hat Developers <https://developers.redhat.com/>
_______________________________________________ platform-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
