Community
Participate
Working Groups
And, wouldn't hurt to do the same for bundle qualifiers :) This bug (and, yes, it is a bug, not an enhancement request! :) continues the discussion started in bug 416583. But in general, we waste too much time having "failed builds" because some qualifier doesn't increment, thus get's "swapped out" by comparator, thus causing failures later since not all qualifiers "line up" or match what is needed. In particular, in bug bug 416583 comment 3 it is was stated "Internally Tycho converts qualifiers to commit dates, and "bump version" commit is necessary if multiple qualifier formats are referenced from the same feature." Now, we've gotten "used to" the fact that if, say, an Orbit bundle changes we must manually "touch" the feature so its qualifier increases ... but even that needs to be improved upon. But, in bug 416583 if was a regular code bundle that was recompiled, and its qualifier was correctly incremented, but the feature that included it did not have its qualifier incremented. Indeed, that feature did include a "mix" of Orbit bundles and "Eclipse code" bundles ... but ... does not exactly explain why qualifier of feature was not incremented. It appears (from "the outside") that the heuristic that decides to increment the feature qualifier is not predictable and deterministic. Is there more we can do in Eclipse Platform? For example, if the Orbit bundles are all listed at end of feature.xml, would that then enable the current heuristic to work? Does the heuristic stop trying, as soon as it detects there is a mix of "qualifier types" in a feature?
Igor has pointed out in bug 416583 that this is documented in http://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers So, it may just be a matter of understanding that, and confirming a) we are not doing something wrong in Platform releng and b) that there is not some bug in Tycho for some situations.
To answer Igor's question in 416583 comment 7, No, we didn't disable feature qualifier check ... But, there are some "not recommended" things we've done for bundles. First, let me say, the document at http://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers implies that "comparator replacement" will happen automatically if that one configuration is copy/pasted into parent pom. If my memory serves, this was not the case, and we had to "turn it on" for bundles, with following "configuration": <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>tycho-p2-plugin</artifactId> <version>${tycho.version}</version> <configuration> <baselineMode>warn</baselineMode> <baselineReplace>common</baselineReplace> <baselineRepositories> <repository> <url>${comparator.repo}</url> </repository> </baselineRepositories> </configuration> </plugin> So, from that, you'll note we set <baselineReplace>common</baselineReplace> instead of the recommnded <baselineReplace>all</baselineReplace> This is because of bug 405911 in build set-up of p2 (which has received zero attention since I opened it). So, perhaps "common" is part of the issue in bug 416583? We also do this only for tycho-p2-plugin ... that is, nothing for "features" ... so we need to "turn on" for features too? Minor twist, we did set a different configuration for "tycho-custom-bundle-plugin" ... this was an attempt to get around the problem we have with JDTs "custom bundle" that shows up as "changed" in comparator log, even when it has not changed ... but shows up as "changed" (I believe) since they do "custom stuff". There we tried setting following configuration, but did not really solve the problem we were trying to solve, so should probably just remove that non-standard configuration to avoid confusion. <plugin> <groupId>org.eclipse.tycho.extras</groupId> <artifactId>tycho-custom-bundle-plugin</artifactId> <version>${tycho-extras.version}</version> <configuration> <baselineMode>warn</baselineMode> <baselineReplace>none</baselineReplace> <baselineRepositories> <repository> <url>${comparator.repo}</url> </repository> </baselineRepositories> </configuration> </plugin> But, again, we never do "turn on" any sort of baselineReplace for features ... is that the problem in bug 416583 (and ... if so, is missing from the documentation).
Just to cross reference, it sounds clear from the logs and discussion in bug 416583 that the problem occurs when a "commit" is cherry-picked from another branch so its "commit date" might be from earlier than the "last versioned feature" ... so, from the features point of view "no recent changes". The bundle doesn't see it as a "recent change", but it sees it as a change and the qualifier updated based on the commit date. Off-hand, one way to fix this is to do more of a "compare" of the feature.xml files ... but, it'd have to be a good "xml diff" compare to avoid spurious differences based on white space or attribute ordering changes. In the mean time, what ever the eventual fix is, committers have to be aware of "the commit date" and if prior to the previous "versioned build" then they will need to either touch the feature, or, maybe easier, "touch" the bundle with a new commit that would have "current date" (which, now that I think of it, may not be completely workable, since then a bundle in "maintenance" (for example) might have same contents as the bundle in master stream, but have an "more recent" qualifier. So, I guess "touching" the feature might be preferred? Complicated. I hope a good solution can be found. FWIW, I've check docs for "commit date" and doesn't seem to any way to specify that during a cherry-pick operation (if at all). Also, I'm not sure if this bug belongs in "CBI" or "Tycho" ... feel free to move if Tycho is better.
(In reply to David Williams from comment #3) > FWIW, I've check docs for "commit date" and doesn't seem to any way to > specify that during a cherry-pick operation (if at all). In Git modifying the commit date is considered rewriting history and a cherry-pick operation does not modify the dates. The approach I would use is to cherry-pick and then before git pushing to the repo. Run a git commit --amend --date="$(date -R)" This will rewrite the cherry-picked commit history and modify the date to the current time. This operation would modify both the Author and Committer dates but I'm not sure how specific you want to be. > Also, I'm not sure if this bug belongs in "CBI" or "Tycho" ... feel free to > move if Tycho is better. I think this bug belongs in Tycho. (moving)
As I mentioned in bug 416583, Tycho git timestamp provider uses commit date, not author date. All git operations increase commit date, so git-cherry-pick, git-am, etc, etc, will never result in a commit date in the past compared to the previous commit on the same branch. In other words, cherry-pick did NOT cause the problem observed in bug 416583. What happened is kinda hard to explain in text, but let me try with an example Lets say you have a git repository repoA with bundleA. There were two recent commits to this repo that touched bundleA, one on 2013-08-01 and another day later on 2013-08-02. The was no bundleA build after 2013-08-02 commit, so the latest bundleA qualifier is 2013-08-01. There is also repoB with featureB; the feature includes bundleA. The feature was last modified and built on 2013-08-10 and published featureA jar includes bundleA 2013-08-01. 2013-08-10 is the latest of the two dates, so feature version qualifier is 2013-08-10. On 2013-08-20 there was new build of bundleA, which got qualifier 2013-08-02 (the time of the most recent change to bundleA). featureA was also rebuilt on 2013-08-20, but because there were no changes in the feature project itself and bundleA was last changed on 2013-08-02, the feature still gets version qualifier 2013-08-10. Of course, in case of Platform there was no "missed" builds, but some of the bundles were held few commits behind with aggregator git repository. Quite honestly, I don't think there is a better way to calculate version qualifiers in this case, but I think Tycho needs to detect and report this problem more eagerly. In fact, Tycho already detects and reports this problem, but projects are allowed to suppress build failure, which I believe is wrong. I need to think some more about this, but I believe we need to remove ability to replace build artifacts when they are different compared to baseline version they are being replaced with. This should be a hard failure with clear error message. I am also not convinced we need "common" replacement mode. It is confusing and even I don't understand what it actually does without re-reading the code. In the mean time, project should really use default <baselineMode> (which will fail the build if build and baseline artifacts have same version but different contents).
(In reply to Igor Fedorenko from comment #5) > In fact, Tycho already detects and reports this problem, but projects are > allowed to suppress build failure, which I believe is wrong. I think you are saying we (Platform build) suppress "failure" .... but, I'm assuming, there is still a warning about it? What's the warning say, about features, specifically? I'd prefer to see the warning instead of stopping everything. > I need to think > some more about this, but I believe we need to remove ability to replace > build artifacts when they are different compared to baseline version they > are being replaced with. This might be the case with "feature.xml" file, but depends on what you mean by "different" ... every signed bundle is "different" than every previously signed bundle due to TSA in "signing signature". > In the mean time, project should really use default <baselineMode> (which > will fail the build if build and baseline artifacts have same version but > different contents). You can read http://wiki.eclipse.org/Platform-releng/Platform_Build_Comparator_Logs to see how we "divide things up", ... or, maybe better, the actual logs from a typical build, such as http://download.eclipse.org/eclipse/downloads/drops4/S-4.4M1-201308072000/buildlogs.php Our goal for now is to try and get "Unanticipated" warning log working well enough we'd know to "fail" then (though more likely a releng test failure, rather than "stop the build" failure). But the "doc" cases and the "signature only" cases are ones where we'd fail each time! Unless I am misunderstaning what you are saying. For the 'common' vs. 'all' issue I have increased the severity of bug 405911.
(In reply to David Williams from comment #6) > (In reply to Igor Fedorenko from comment #5) > > > > In fact, Tycho already detects and reports this problem, but projects are > > allowed to suppress build failure, which I believe is wrong. > > I think you are saying we (Platform build) suppress "failure" .... but, I'm > assuming, there is still a warning about it? What's the warning say, about > features, specifically? I'd prefer to see the warning instead of stopping > everything. Correct. Platform build explicitly suppressed failure in this case. Look for a warnings like this in build logs [WARNING] MavenProject: org.eclipse.e4.feature:org.eclipse.e4.rcp:1.2.1-SNAPSHOT @ /var/tmp/cbi/eclipse.platform.releng.aggregator/eclipse.platform.ui/features/org.eclipse .e4.rcp/pom.xml: baseline and build artifacts have same version but different contents no-classifier: different META-INF/ECLIPSE_.RSA: present in baseline only META-INF/ECLIPSE_.SF: present in baseline only feature.xml: different > > > I need to think > > some more about this, but I believe we need to remove ability to replace > > build artifacts when they are different compared to baseline version they > > are being replaced with. > > This might be the case with "feature.xml" file, but depends on what you mean > by "different" ... every signed bundle is "different" than every previously > signed bundle due to TSA in "signing signature". Entries that are expected to differ should be excluded from comparison. I am not sure Tycho provides a way to do this, but this is something we can fix. For entries that are expected to be the same, this is really a hard failure; the build results are guaranteed to be invalid. You, Dani and I likely spent over 24 hours in total troubleshooting this, waiting for the new build, etc. This is pure waste that could have been prevented by better error reporting in Tycho. > > In the mean time, project should really use default <baselineMode> (which > > will fail the build if build and baseline artifacts have same version but > > different contents). > > You can read > http://wiki.eclipse.org/Platform-releng/Platform_Build_Comparator_Logs > to see how we "divide things up", ... or, maybe better, the actual logs from > a typical build, such as > http://download.eclipse.org/eclipse/downloads/drops4/S-4.4M1-201308072000/ > buildlogs.php > > Our goal for now is to try and get "Unanticipated" warning log working well > enough we'd know to "fail" then > (though more likely a releng test failure, rather than "stop the build" > failure). > But the "doc" cases and the "signature only" cases are ones where we'd fail > each time! > > Unless I am misunderstaning what you are saying. > > For the 'common' vs. 'all' issue I have increased the severity of bug 405911. 'common vs all' is really an edge case, overengineering/overanalising on my part, it should be possible to handle without asking users make choices that can't make.
(In reply to Igor Fedorenko from comment #7) > (In reply to David Williams from comment #6) > > (In reply to Igor Fedorenko from comment #5) > > Correct. Platform build explicitly suppressed failure in this case. Look for > a warnings like this in build logs > > [and] > > You, Dani and I likely spent > over 24 hours in total troubleshooting this, waiting for the new build, etc. > This is pure waste that could have been prevented by better error reporting > in Tycho. Yes, we had such a warning in this case, but, remember, the build did fail. I think we knew fairly quickly the basic reason why (that the feature had to be "touched") and the 24 hour mystery was "why did the feature have to be touched, when the bundle commit was just made?". And, you have explained that "hard to explain" issue, by example, but I'm not sure I'd be able to put into words so a committer would know, before doing the build, how they could tell if they had to 'touch a feature' or not (much less, program a "check" that could tell automatically :) > Entries that are expected to differ should be excluded from comparison. I am > not sure Tycho provides a way to do this, but this is something we can fix. Yes, this could be improved for the "signature files" ... to do it right, for "signatures", would have to verify only the TSA changed, as it does every build, and not the cert itself, which (historically) changes every 3 years (at Eclipse.org). > For entries that are expected to be the same, this is really a hard failure; > the build results are guaranteed to be invalid. IMHO, this is a little harder to claim ... don't get me wrong, I think you are correct in a strict literal sense, ... but I think in practice it is not a "hard line" but filled with gray areas. Particularly given the way we work, with frequent I-builds, leading to milestones, leading to release. One common case from my experience: we change the compiler ... it "optimizes" some null checks in a better way to avoid a few wasted byte codes ... yes, by the release, we definitely want those bundles "touched" so they all "match" what the compiler is producing ... but, for an I-build? In the past, we've often said "wasn't important enough to hold up the I-build" ... hence, having the build with a "hard failure" until all of, say, the 20 or 40 bundles had been "touched" would typically be seen as a bad thing, by most committers, I believe. Some projects would be fine even releasing, if only difference was "optimized byte codes" ... now, if an in-lined constant was to blame, then yes, that's obviously a "hard error" that would have to be re-spun, even for an I-build, most likely. I know I'm probably being overly wordy, and "writing the obvious", but want to emphasize I am really just trying to relate my experience in using "comparator" for 5 or 7 years ... I'm not trying to argue "right and wrong" ... if PMC or all the other committers on a project decided "yes, we want that flagged as a hard error, no matter what" ... fine ... but I think they should have to option of deciding "for our project, let's count it as a warning and let someone investigate if it is significant enough to warrant a rebuild". And, let's face it, if we knew so much, and had so much confidence in the comparator's perfect accuracy ... then why have a "failure" at all ... why not just decide, "oh, in this case at least the qualifier needs incrementing, so let's do that, keep the current (just built) version, log an informative message, and keep building. Yes, incrementing the qualifier would need some "suffix adding" algorithm ... or something ... but, IMHO, the reason it is not worth investing in that, is that the "comparator" may be correct in saying two artifacts are different ... but they may not be significant differences and a) everyone's (project) opinion of what's significant may be different, and b) that may change over time (or point in dev. cycle). Back to the subject ... maybe a "git-like-picture" would help explain "how auto-qualifier-versioning" works and "how to tell if feature needs to be incremented"? (e.g. elaborate on pictures similar to http://marklodato.github.io/visual-git-guide/index-en.html#cherry-pick ) [I am not volunteering :) ... just rambling. :/ ]
Now I remember, we already had this argument. To sum up. Artifact comparator isn't perfect and there is a class of changes detected by comparator that do not affect semantics of the code. The tradeoff we have, either allow developers manually review all such cases (and possibly miss "real" differences) or force developers bump version for any detected difference. ~~~~~ Artifact comparator can tell the version needs to change, but qualifier calculation logic can't provide new reproducible qualifier. ~~~~~ I leave this bug open for future references, but have no plans to work on this unless we agree to make artifact comparator report errors more aggresivly or somebody suggest more reliable way to calculate version qualifiers. I still believe forcing new version for any detected change is a better tradeoff, but you won the argument last time and I don't want to repeat this discuss again. For any future questions about Tycho artifact comparison and version qualifier generation I respectfully ask Platform team to provide small *standalone* example to illustrate the question.
As Dani Megert pointed out in https://bugs.eclipse.org/bugs/show_bug.cgi?id=436039#c15 it is possible to add new commits to a branch with commit date arbitrary far back in the past with fast-forward merge. I think this means Tycho can produce new build qualifier that will be considered older that the baseline or same qualifier but different contents. Still don't know what to do about this.
The fact that feature.xml files are updated as part of a build mean that they are in a sense "generated source", and you can't rely on the most recent commit date on the file to inform you of its contents. The only two ways to deal with this are to either track all of the changes to the "sources" that affect the generated content (which in this case means tracking the version numbers of the bundles whose qualifiers are being updated in the feature.xml file), or directly comparing the contents of the locally updated feature.xml file with that in the baseline version. In either of these cases, it only tells you that the locally built feature bundle is incompatible with the baseline version, it doesn't give you a new reproducible qualifier. I think you would need to enhance the qualifier of feature bundles with a hash of the contents of the "generated sources", e.g. "v<date-time>_N_<hash>", where "N" would need to be incremented from its value in the baseline version. But I'm not terribly happy with that, because it would only work so long as you were very disciplined about updating your baseline version from build to build. A non-solution that might make things better would be to automate the "forceQualifierUpdate.txt" workaround by replacing those files with the generated "feature.xml" files (perhaps named "previously_generated_feature.xml"), and if a locally generated feature.xml file doesn't match the previous version, staging a commit to the "previously_generated_feature.xml" file and failing the build with an appropriate error message.
Tycho already tracks versions of all included bundles and compares feature to the baseline, but this is not enough to reliably handle commits in the past, when the current implementation may produce either the same or even "earlier" qualifier compared to baseline. I am not attached to the current implementation and will be happy to help review and merge a better one. Here are the basic requirements * Whenever feature contents changes, new version qualifier must be produced. * New version qualifier must be "newer" compared to the baseline version qualifier according to OSGi/P2 version comparison rules * Rebuilding the feature from the same sources and with the same contents must produce the same version qualifier as the baseline There is also baseline comparison logic that is meant to detect when version qualifier calculation misfires and provide extra layer of safety. Currently it can only detect same-qualifier-different-contents case, but I think it should also enforce "new-qualifier-must-be-newer-than-baseline" rule. If somebody is interested to contribute, I can explain how current qualifier calculation logic works and provide other pointers on tycho-dev. Also, automatic version qualifier is an optional Tycho feature, you don't have to use it if it misbehaves too often to be useful.
(In reply to Igor Fedorenko from comment #12) > Tycho already tracks versions of all included bundles and compares feature > to the baseline, but this is not enough to reliably handle commits in the > past, when the current implementation may produce either the same or even > "earlier" qualifier compared to baseline. > This is not what I am seeing, so perhaps I should be opening a new bug. What I am seeing is reliably reproducible using the Eclipse CBI build: 1) Clone all of the Eclipse CBI repos. 2) Create a new branch based on an integration tag from several days ago. Make sure there has been at least one commit to the eclipse.platform.runtime repo since the integration build, and that the newer commits don't affect the org.eclipse.core.jobs plug-in (the Jobs API is quite stable so this a safe bet). 3) Cherry pick the patch for bug 432049: git fetch git://git.eclipse.org/gitroot/platform/eclipse.platform.runtime refs/changes/72/24472/3 && git cherry-pick FETCH_HEAD 4) In the eclipse.platform.releng.tychoeclipsebuilder/pom.xml file remove everything from the <modules> section other than "rcp.config" and "sdk". 5) Build on the branch. This succeeds. 6) Merge changes from master into the newly created branch in the eclipse.platform.runtime repo. 7) Build on the branch. This fails in the final org.eclipse.sdk.ide assembly. In both builds, the locally generated feature.xml file look good, with a correctly updated version for the org.eclipse.core.jobs plug-in. In the first build, the org.eclipse.e4.rcp feature is created with version 1.3.100.v20140523-2335, which differs from the baseline, but after the merge from master, that feature is created with version 1.3.100.v20140515-1607, which matches the baseline, and thus gets overwritten by the baseline, causing the build to fail.
I am not currently in the position to troubleshoot Eclipse Platform build. Somebody will have to either provide provide a small standalone project I can use to reproduce the problem or, better yet, a quality patch to fix the problem.
FWIW, I've documented "Tips on making sure qualifiers increment correctly", at https://wiki.eclipse.org/Platform-releng/Platform_Build_Automated#Tip_on_making_sure_qualifiers_increment_correctly And hope to "educate" our committers with that. If any of you knowledgeable in this area have a chance to review/correct/improve, please do. Especially the last paragraph "Therefore, especially during critical periods, such as "right before a milestone or release", if you change a bundle, you will want to strongly consider proactively "touching" the feature (or, features, if contained in several) to make sure they are correctly incremented, instead of depending on the automatic computation. Ironically, this problem is worse, when we do frequent I-builds (since that serves as the basis for the comparator "swapping out" items whose qualifier has not changed) since then it is more likely "the most recent" commit has already incremented a feature's qualifier in that repo -- and an older "commit", even though more recently pushed, will not be "picked up" in already qualified feature." = = = = = = = = = If I may, I'm wondering if some "tooling" would help a little ... before we get a "perfect" system. For similar (but different topic) example, we added "IDE warnings" if POM version did not match MANIFEST version so as long as committer enable it, they don't have to wait until a build runs, with "pom updater", to discover the issue. Do you think it feasible a tool could be written that might show, for a given feature, which bundle, or feature, will effect the features qualifier. If so, that might allow committers to have a means to "sanity check" the effect of them pushing a change to repo? And thus help them know if they need to use "forceQualifierUpdate.txt", or not? And, I am just asking for advice ... not asking you to do it :) ... I just wanted to be sure I was clear on how such a tool would work ... go through each item in a feature, getting a list of "most recent commit times" ... and then (somehow) displaying "qualifier will be determined by xyz commit, in bundle abc" Have I over simplified? or would that be useful for many of these problematic cases?
Any chance of this issue being addressed any time soon? It creates a nightmare for people running their own Eclipse Platform builds turning the process into a sequence like: 1. Start a Maven build of the Eclipse Platform. 2. Watch the build is running for 3.5 hours. 3. Build fails with an error message: "You requested to install 'bundle org.eclipse.some.plugin 0.0.0' but it could not be found". 4. Try to guess the forceQualifierUpdate.txt file to update, change the file, commit, push. 5. Repeat the above steps again and again until you guess the correct forceQualifierUpdate.txt files for all plugins that "could not be found". The whole process can easily take days.
To cross reference, bug 467923 documents another mysterious case, that is not well understood "what caused the problem". In that case, we did one build, all was fine, needed a rebuild a few hours later, with one fix in it, one that had nothing to do the "JDT", but the build failed because the JDT feature needed to be "touched" ... makes no sense, to us. But, does makes me wonder if there's an "obvious" disconnect. Our "branding bundles" are updated with current date/time (The time of the build, as reflected in the buildId). There is no commit associated with these new versions, they are computed at build time, but makes me wonder if they do, or should, influence the feature version for which they are the branding bundle. AND (what I am really wondering) does it matter that "buildId" is determined from "date time" in Eastern Time zone, but git commits are in units of UTC time zone. In other words, a four (or five) hour window that "time of build" would always be "earlier" than previous Git commits. I could be way off base here ... just thought I'd ask, if anyone has an intuition about it. (It's be easy to "run our build" with UTC time, if someone said "yes, it would make a difference). = = = = = (In reply to Sergey Prigogin from comment #16) > Any chance of this issue being addressed any time soon? Unlikely. But if it really takes you days, depending on your purposes, you might right a script that goes though and touches all the "forcequalifierupdate.txt" files, for features.
I wonder if recent fix for bug 482086 (see release notes [1] and updated docs [2] ) fixes this one too? [1] https://wiki.eclipse.org/Tycho/Release_Notes/0.25#Feature_Version_Qualifiers [2] https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers#Feature_version_qualifiers
(In reply to Jan Sievers from comment #18) > I wonder if recent fix for bug 482086 > > (see release notes [1] and updated docs [2] ) > > fixes this one too? > > [1] > https://wiki.eclipse.org/Tycho/Release_Notes/0.25#Feature_Version_Qualifiers > [2] > https://wiki.eclipse.org/Tycho/ > Reproducible_Version_Qualifiers#Feature_version_qualifiers Sounds ok by me. It is a fair improvement. A couple of questions and comments first, then you can decide if your answers "completes" the documentation. A. So, features are supposed to work "hierarchically", right? Even if included in more than one other feature? I just ask because "deeply nested, reused features" seems to occasionally cause problems for us) -- and that's with/without an "Orbit change". B. The "timestamps" from pre-existing binary jars may still be "before" the most recent change in Git, so I think a manual "bump" in feature version would still be needed then. Right? (That is, the heuristic does not detect "changes from before" ... just time stamps and compares them with Git changes). [And, don't get me wrong ... still an improvement, I think]. C. Just FYI, for "fun", I tabulate the pattern of version qualifiers that people use in Sim. Release. For example, see https://hudson.eclipse.org/simrel/job/simrel.mars.runaggregator.BUILD__CLEAN/lastSuccessfulBuild/artifact/aggregation/final/buildInfo/reporeports/reports/versionPatterns.txt Your heuristic covers most, of course, but not all. Just thought you might be interested in seeing the variety used.
(In reply to David Williams from comment #19) > > B. The "timestamps" from pre-existing binary jars may still be "before" the > most recent change in Git, so I think a manual "bump" in feature version > would still be needed then. Right? (That is, the heuristic does not detect > "changes from before" ... just time stamps and compares them with Git > changes). > There is always a risk that "new" binary bundle timestamp is "older" than timestamp of some other bundle included in the feature. This is fundamental limitation of the current feature timestamp generation approach.
Eclipse Tycho is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/tycho/issues/ instead. If this issue is relevant to you, your action is required. 0. Verify this issue is still happening with latest Tycho 2.4.0-SNAPSHOT if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done if issue is still present when latest release: * Create a new issue at https://github.com/eclipse/tycho/issues/ ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience) ** In the GitHub description, start with a link to this bugzilla ticket ** Optionally add new content to the description if it can helps towards resolution ** Submit GitHub issue * Update bugzilla ticket ** Add to "See also" property (up right column) the link to the newly created GitHub issue ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>" ** Set status as CLOSED MOVED ** Submit All issues that remain open will be automatically closed next week or so. Then the Bugzilla component for Tycho will be archived and made read-only.
