Community
Participate
Working Groups
Once we have two "full builds" running, it is very likely many of the bundles will have the exact same version/qualifier. But, all of them may have slightly different content. The time of signing, perhaps exact time of the build in an about.ini file, etc. So, not good already, but no functional harm; they would in interchangeable. But, in hallway chats with John, he thought in theory, any bundles that consumed workbench.ui could actually have byte code differences, in theory, if some constant changed, some method signature?, some hierarchy change? So in this case, having same version/qualifier would be especially bad. (such as someone updating from 3.8 to 4.2 might need the 4.2 version, but would not get updated, since they already had it for 3.8. So, the deluxe solution would be to do a "two phase" comparator step, mirror once comparing to the streams own historical repo, as we do now, but then also, have a new step to mirror 3.8 against 4.2 repo (or, vice versa) ... so, then we'd get an "old" bundles already built (with same version/qualifier) and the comparator would warn us of problems that required intervention to fix. There might be other solutions, such as to prefix or suffix the whole 3.8 build, say with _R38 and I guess 42 builds with _R42 (if suffix, we'd need to make sure incremented from 3.8 to 4.2 for updates to work right). This seems kind of ugly (and not in the spirit of versioning/qualifiers) ... and could be other issues ... but, thought it worth discussing (since the two phase comparator would be a fair amount of work). Any other ideas?
The current method/situation isn't great, but I don't plan to do anything here, unless someone finds a specific problem (or in the very unlikely event we don't move to maven/tycho).
