Bugzilla – Full Text Bug Listing
| Summary: | End of support for Galileo (3.5) and Helios (3.6) with EGit 2.2 (planned for 2012-12-15) | ||
|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Matthias Sohn <matthias.sohn> |
| Component: | Core | Assignee: | Project Inbox <egit.core-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | caniszczyk, curtis.windatt.public, daniel_megert, hubert+eclipseorg, john.arthorne, markus.kell.r, pascal.rapicault, pascal, pwebster, remy.suen, robin.rosenberg, robin, steffen.pingel, Szymon.Brandys, tomasz.zarna |
| Version: | unspecified | ||
| Target Milestone: | 2.2 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 327381, 372112 | ||
|
Description
Matthias Sohn
- the org.eclipse.egit.ui.internal.history.GitCreatePatchWizard.getOrCreateSection(IDialogSettings, String) method could be removed as this is a copy of org.eclipse.jface.dialogs.DialogSettings.getOrCreateSection(IDialogSettings, String) added in 3.7 Matthias, is your plan to drop 3.5 but still support 3.6? Or, what will the new minimum version be? So no chance for 3.8 and bug 366790 in the nearest future? Note that support for SCM URLs has been added to Team in 3.7 (bug326926, bug 330490). (In reply to comment #4) > So no chance for 3.8 and bug 366790 in the nearest future? Note that support > for SCM URLs has been added to Team in 3.7 (bug326926, bug 330490). Not moving to 3.8 would mean no chance for a nice fix for bug 327381 which has been a major regression for us since we switched from the Eclipse CVS client to EGit. Unless EGit moves to 3.8, we could address bug 327381 in two other ways: 1) Add a separate bundle to EGit that contributes extensions described in bug 327381. This bundle would have a dependency on team.core version from Eclipse 3.8. So it would be loaded and used only when EGit is installed on Eclipse 3.8. 2) Just add these extensions to egit.core manifest. AFAIK if there is no right extension, they will be silently ignored. So for EGit on Eclipse prior to 3.8, it would do nothing. Thoughts? (In reply to comment #5) > 2) Just add these extensions to egit.core manifest. AFAIK if there is no right > extension, they will be silently ignored. So for EGit on Eclipse prior to 3.8, > it would do nothing. You only need to specify a dependency if you are referencing classes from another bundle. You don't need to declare a bundle dependency just to create an extension to another bundle's extension point. So, this sounds like a possible option but I think we should continue that discussion in bug 327381. Another one to be added to the list from comment 0: - https://git.eclipse.org/r/#/c/5134/ : "InstanceScope() and DefaultScope() constructors are deprecated", should read: _will_ be deprecated after switching to 3.8 I propose we drop support for Galileo and Helios with EGit 2.0 We can also get rid of org.eclipse.egit.psf-feature, which was only needed for a dependency on org.eclipse.core.runtime.compatibility for 3.6 and earlier. (In reply to comment #8) > I propose we drop support for Galileo and Helios with EGit 2.0 +1. Can we close? It looks like changes got merged that make this a fact, e.g. https://git.eclipse.org/r/5134 (In reply to comment #12) > It looks like changes got merged that make this a fact, e.g. > https://git.eclipse.org/r/5134 InstanceScope.INSTANCE and the others they are available since 3.4 (at least that's what the Javadoc says), so we still support 3.5. Or are there other changes breaking compatibility? (In reply to comment #13) > (In reply to comment #12) > > It looks like changes got merged that make this a fact, e.g. > > https://git.eclipse.org/r/5134 > > InstanceScope.INSTANCE and the others they are available since 3.4 (at least > that's what the Javadoc says), so we still support 3.5. Or are there other > changes breaking compatibility? Bundles start at 1.0 when added/introduced and use @since tags that refer to their own bundle number. The bundle version is not connected to release numbers at all unless that bundle was present in Eclipse 1.0. So, either that change needs to be reverted or 3.5 and 3.6 support ended and this closed. (In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > It looks like changes got merged that make this a fact, e.g. > > > https://git.eclipse.org/r/5134 > > > > InstanceScope.INSTANCE and the others they are available since 3.4 (at least > > that's what the Javadoc says), so we still support 3.5. Or are there other > > changes breaking compatibility? > > Bundles start at 1.0 when added/introduced and use @since tags that refer to > their own bundle number. The bundle version is not connected to release > numbers at all unless that bundle was present in Eclipse 1.0. Ugh, ok. I assumed it corresponded to the Eclipse versioning as the package is "org.eclipse.core", and nobody corrected my comment on the review. Sorry for causing this confusion. Is there an overview of these versions somewhere? So org.eclipse.equinox.preferences 3.4 was first in Eclipse 3.7? > So, either that change needs to be reverted or 3.5 and 3.6 support ended and > this closed. I would say revert, as the above change just removes some annoying deprecation warnings, and we still have some users on 3.5 and 3.6. Review for revert: https://git.eclipse.org/r/8514 (In reply to comment #15) > Is there an overview of these versions somewhere? You can look at a build (About dialog or 'plugins' directory) which bundles are included but there is no documentation that shows which version is in which release. But that doesn't really matter. If a project like EGit defines that it runs against 3.5 then the developers should set the PDE target to a 3.5 install. This avoids the usage of improper APIs or the acceptance of patches with such. > org.eclipse.equinox.preferences 3.4 was first in Eclipse 3.7? Yes, in 3.7 its version was increased to 3.4.0. (In reply to comment #16) > Review for revert: > > https://git.eclipse.org/r/8514 Can't we move forward. We've long ago established the principle of only supporting the two latest versions. By accident 3.5 and 3.6 have continued to work. (In reply to comment #17) > (In reply to comment #15) > > Is there an overview of these versions somewhere? > > You can look at a build (About dialog or 'plugins' directory) which bundles > are included but there is no documentation that shows which version is in > which release. But that doesn't really matter. If a project like EGit > defines that it runs against 3.5 then the developers should set the PDE > target to a 3.5 install. This avoids the usage of improper APIs or the > acceptance of patches with such. You really need to test against both older and newer Eclipse versions. (In reply to comment #12) > It looks like changes got merged that make this a fact, e.g. > https://git.eclipse.org/r/5134 (In reply to comment #18) > (In reply to comment #16) > > Review for revert: > > > > https://git.eclipse.org/r/8514 > > Can't we move forward. We've long ago established the principle of only > supporting the two latest versions. By accident 3.5 and 3.6 have continued > to work. yes, I think we should move forward, this was my intention when filing this bug. If we agree on that I'd update the title of this bug accordingly to EGit 2.2 and close it. Ok, let's move forward. Can we keep this open until we have done all the cleanup?: - Remove org.eclipse.egit.psf-feature (no longer needed) - Remove old target platforms (pom.xml and .target files) - More? (In reply to comment #19) > (In reply to comment #17) > > (In reply to comment #15) > > > Is there an overview of these versions somewhere? > > > > You can look at a build (About dialog or 'plugins' directory) which bundles > > are included but there is no documentation that shows which version is in > > which release. But that doesn't really matter. If a project like EGit > > defines that it runs against 3.5 then the developers should set the PDE > > target to a 3.5 install. This avoids the usage of improper APIs or the > > acceptance of patches with such. > > You really need to test against both older and newer Eclipse versions. Well, test yes. But using the lowest target is enough regarding API - at least for the Eclipse SDK code which is upwards API compatible. At any rate, using the lowest target is better than using the latest. (In reply to comment #21) > Ok, let's move forward. This is something that the project lead(s) or even the PMC have to decide and comment here. As said in comment 10 I'm also in favor of moving forward. AFAIK we never promised to support older releases than the last two platform releases, this is documented in [1]. That we still support Galileo is due to the fact that nobody found time to start the clean-up. [1] http://wiki.eclipse.org/EGit/FAQ#What_versions_of_Eclipse_does_EGit_target.3F +1 to moving forward We've long ago established a very sensible and transparent policy that we will only support the two latest versions of Eclipse: http://wiki.eclipse.org/EGit/FAQ#What_versions_of_Eclipse_does_EGit_target.3F We can also be used as a carrot for people to move forward to a newer release of Eclipse if they want to use a newer version of EGit. If not, they use an older and officially supported version. Prepared changes: > - Remove org.eclipse.egit.psf-feature (no longer needed) https://git.eclipse.org/r/8542 > - Remove old target platforms (pom.xml and .target files) https://git.eclipse.org/r/8543 (In reply to comment #26) > Prepared changes: > > > - Remove org.eclipse.egit.psf-feature (no longer needed) > > https://git.eclipse.org/r/8542 merged as 70c892198c8519422abec216c505c28523e72a2c > > - Remove old target platforms (pom.xml and .target files) > > https://git.eclipse.org/r/8543 merged as ad9ef860a073f03f541303e38d0a33f02ff04962 (In reply to comment #27) > (In reply to comment #26) > > Prepared changes: > > > > > - Remove org.eclipse.egit.psf-feature (no longer needed) > > > > https://git.eclipse.org/r/8542 > > merged as 70c892198c8519422abec216c505c28523e72a2c This can break clients who refer to that feature, see e.g. http://dev.eclipse.org/mhonarc/lists/egit-dev/msg02924.html > This can break clients who refer to that feature, see e.g.
> http://dev.eclipse.org/mhonarc/lists/egit-dev/msg02924.html
Any hints how to fix this ? Does p2 provide a way to uninstall the feature on upgrade ?
(In reply to comment #29) > > This can break clients who refer to that feature, see e.g. > > http://dev.eclipse.org/mhonarc/lists/egit-dev/msg02924.html > > Any hints how to fix this ? Does p2 provide a way to uninstall the feature > on upgrade ? Pascal, can you give an advice here? isn't that fixed by https://git.eclipse.org/r/#/c/8857/ ? (In reply to comment #31) > isn't that fixed by https://git.eclipse.org/r/#/c/8857/ ? Not 100%, I guess since that fixes the p2 / install problem but not the case where a product directly references/requires the feature. Not sure how important that case is though. Let me first start by summarizing the situation: - You want to get rid of a feature, however there are other features or products depending on it, so people won't be able to move forward. Solution (for what I understood is the problem :)) - Since you can't get rid of the dependencies on the feature to be removed, you have two possibilities. 1) Don't remove the feature from the build, but instead just empty it. This way the dependencies are still satisfied. The advantage of this approach is that it is simple to put in place. The drawback is that you still build and ship this feature. 2) Remove the feature from the build, but have another feature or plugin pretend being the removed feature. This is what I refer to "identity theft". A plugin or feature pretend being another IU. This can be achieved by having a p2.inf providing the capabilities of the removed feature. The advantage with this approach is that you actually get rid of the feature. (In reply to comment #33) > Let me first start by summarizing the situation: > - You want to get rid of a feature, however there are other features or > products depending on it, so people won't be able to move forward. > > Solution (for what I understood is the problem :)) > - Since you can't get rid of the dependencies on the feature to be removed, > you have two possibilities. > 1) Don't remove the feature from the build, but instead just empty it. > This way the dependencies are still satisfied. The advantage of this > approach is that it is simple to put in place. The drawback is that you > still build and ship this feature. > 2) Remove the feature from the build, but have another feature or plugin > pretend being the removed feature. This is what I refer to "identity theft". > A plugin or feature pretend being another IU. This can be achieved by having > a p2.inf providing the capabilities of the removed feature. The advantage > with this approach is that you actually get rid of the feature. I think my change https://git.eclipse.org/r/#/c/8857/ implements 2) or do I miss something ? I think this is fixed with change https://git.eclipse.org/r/#/c/8857/ |