[ https://issues.jboss.org/browse/JBIDE-13671?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-13671: --------------------------------------------- {quote} "If you use a different TP that affects the feature.xml resolution of what the 0.0.0 refers to does it not ? Thus it will behave differently since the content is actually different." If you mean at install time, yes, but changing the version of the feature.jar won't change that behaviour. We already have this feature-not-a-bug which allows us to change the TP without updating JBDS, or change JBDS without changing the TP. They can move independently and p2 handles it. {quote} You are mixing two things here. That P2 can handle resolution dynamically is all fine and well handled, but this assumes that when something is called v1.2.3-<someuniquevalue> that this 1.2.3 have the same kind of metadata in place so P2's handling will be deterministic. If you have two v1.2.3 available with different metadata associated with it (which happens when building with different TP's and don't change the semantic version) available to P2 then the resolution will be/could end up different will it not ? {quote} If you mean at build time, no, because we don't package our TP artifacts into the features. We only depend on them; we do not include them. So the depend relationship continues to be to "the version available at build time" rather than "a specific version we've bundled up into this update site". {quote} Does this "the version available at build time" not exactly mean that we cannot keep using the same version between builds since the behavior will be different. {quote} "why don't we delete the new duplicates ?" Do you mean we would merge old plugins built a month ago (with the same timestamp/SHA) into a new CI build's update site, rather than using the freshly-rebuilt-from-the-same-SHA ones? {quote} Yes. since you keep claiming they are the same, so why generate a new one. {quote} Because... Maven doesn't do that, and if we wanted to write our own "compare with old baseline and copy identically-timestamped IUs into the new CI site" we could. But given the fact that the same sources are used, surely the same output is produced, making the two jars bitwise nearly identical? {quote} Just having the same sources does NOT imply same behavior. Youself just stated twice above that the TP is used at buildtime which affects how p2 handles updates so they are not identical, right ? {quote} "how are you going to support not having a maintanence branch and product branch for developer studio" When we create the first CR build for 4.4.0.Final / 10.0.0.GA), we would THEN cut a 4.4.x maintenance branch, in order to have a place to work on JBT 4.5 / DS 11. But we won't need all the milestoneX (jbosstools-4.3.0.Beta1x, jbosstools-4.3.1.Beta1x, etc.) branches we currently use - all that extra churn and burn goes away in the interest of being more agile. {quote} Neither of the milesteoneX branches are not maintanence branches. I'm talking about the actual maintanence branches which in this new model would now need to be checked more for not having overlapping versions. {quote} " if you installed month later you get the new one, but if you update you stay on the old build." This is only true if the feature versions don't change while the plugin versions DO. But according to Tycho's doc, if a contained plugin changes, so too will the feature version change: https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers#Feature_ve... {quote} That only describes the timestamp - it does not change the semantic part of the version and thus it exactly reveals the issue I mentioned. That if you installed v1.2.3-<sometimestamp> a month ago installing vs updating v1.2.3-<othertimestamp> today could/will behave in different installation. Right ? {quote} Oh, and note too: Please note that if a feature directly includes bundles or features not part of the same code base but consumed via a target platform, the stability of a reproducible feature version qualifier also depends on the stability of the target platform in addition to the stability of the code base. If a rebuild occurs with a change in target platform, a different feature version qualifier might be generated. {quote} Exactly the problem we have - the docs here in tycho is describing what the reproducible_version_qualifers mechanism does to ensure it does not end up with the exact version qualifier even though the SHA1 version is the same. That does not change that the base version of the feature will stay the exact same. {quote} So... TL;DR, Denis and I both like this idea. {quote} Cool - [~dgolovin] know these issues so would be great to hear his answer to these. {quote} Only major concern I've seen raised from Max (in March 2013) is "to get rid of snapshot dependencies first - maven deps, parent pom, target platform, maven plugins. Not tycho/p2-deps." I'm not convinced that any of the other concerns raised are real issues, only fears of the unknown. {quote} These are the exact same issues normal releng cringes over having to deal with. That a build today using SNAPSHOT dependencies will not be the same when done tomorrow. Please clarify why you think that is considered "unknown". It is very known afaics. {quote} So, to address the question of "maven deps, parent pom, target platform, maven plugins", I need more information. Max, can you clarify how changing the plugins/feature versions will impact our existing dependency on these upstream artifacts? {quote} Okey, I'm now very confused - I read this jira as to *not* change the plugin/feature versions when we do builds. Using last-mod-timestamp = the version of the build plugin/feature stays the same no matter if "maven deps, parent pom, target platform, maven plugins" using SNAPSHOT has changed. So lets say we use a snapshot of a maven-plugin, 1.2-snapshot - you do a build of a bundle it gets version 1.2.3-v12345 based on the sha1. Now you change something in maven-plugin 1.2-snapshot, lets say it uses a new version of tycho and changes behavior to include something new into the bundle. You rebuild your bundle with zero changes, still referencing 1.2-snapshot, if the build continues to work the generated bundle is still 1.2.3-v12345 but it is now *different* than the previous built one. All because you used a SNAPSHOT version for the maven plugin. {quote} Further, if we released a parent pom 4.4.0.Final (not snapshot) and allowed no more parent pom changes for the rest of the 4.4.0.x development cycle, would that allay fears? If we do that, then the only way to release new TPs and have them used by devs/Jenkins would be ... commandline flags, which is non-ideal. Open to better ideas - I'm all out. {quote} I don't have a good answer since this is the whole problem. I could live with the parent pom having snapshot and was very well managed and TP's was the only change we did - but the use of snapshots in lots of dependencies of maven and updatesites makes this non-trivial to solve. Best suggestion I have is to see if there is a way to test if the jar changed contents/behavior while still having same exact three part version number. But that just seems very very slow. -- This message was sent by Atlassian JIRA (v6.4.11#64026)