Community
Participate
Working Groups
http://dev.eclipse.org/mhonarc/lists/platform-swt-dev/msg07373.html Why was this split done? In master, SWT's MANIFEST.MF still says 3.8.0, but the library version is 4.229 now. Note that API changes were done with M6, and increasing the major version of a bundle is even a breaking change. Unless you have PMC approval and must break APIs, I don't see a good reason for this split. If you don't change the version in the manifest, then you still have 2 different versions of SWT in the 3.8 and 4.2 streams, which is quite confusing and cries for compatibility problems.
AFAIK this was done because CTabFolder is different in 3.8 and 4.2 (different implementation, different behaviour). I guess the master version of SWT has to be updated in the R4_HEAD branch of eclipse.platform.releng.maps. PW
FWIW, bug 377980 is where the change for CTabFolder is discussed. But, I agree, it'll be a tricky issue to explain the the community ... if they care nothing about CTabFolder, they might be better off specifying a "wide" range, such as [3, 4), but ... If they do use CTabFolder, then developing for 4.2 specifically, they'll need to be careful specify a pretty specific lower limit ... of what? [3.8.0.v4229a, 4) [including Eclipse IDE for 4.2?) and for their 3.8 versions, they'll have to specify an unusual limit of, what, say [3.0, 3.8.0.v4000) ? There are also probably ways to "restrict" the use of which bundle (package) to use by using "export/import packages" and special "attributes" for the package that must match for producer and consumer must coordinate if the consumer cares. I don't know enough about swt (nor OSGi :) to give specific advice, but it'd be something like SWT would export-package org.eclipse.swt.custom... ; customctab=true; version = xxx and for 3.8 implementation something like export-package org.eclipse.swt.custom... ; customctab=false; version = xxx so if someone didn't care, they'd could still say import-package org.eclipse.swt.custom... (and either package would "match") or if they wanted the 4.2 specific version, that had the "new ctab implementation" they'd say something like import-package org.eclipse.swt.custom...; customctab=true Sorry not to be able to give more concrete advice ... and, maybe you already have all this figured out ... but, you do need to communicate to community how to control which they get.
(In reply to comment #1) > AFAIK this was done because CTabFolder is different in 3.8 and 4.2 (different > implementation, different behaviour). > > I guess the master version of SWT has to be updated in the R4_HEAD branch of > eclipse.platform.releng.maps. > > PW Such a change would need PMC approval after the API freeze.
(In reply to comment #2) > But, I agree, it'll be a tricky issue to explain the the community ... if they > care nothing about CTabFolder, they might be better off specifying a "wide" > range, such as [3, 4), but ... > > If they do use CTabFolder, then developing for 4.2 specifically, they'll need > to be careful specify a pretty specific lower limit ... of what? [3.8.0.v4229a, > 4) [including Eclipse IDE for 4.2?) and for their 3.8 versions, they'll have to > specify an unusual limit of, what, say [3.0, 3.8.0.v4000) ? For Platform/UI when we remained API compatible [1] but changed most of our internal behaviour, we bumped our minor version to 100. So 3.100.0 would be consistent with a change in behaviour. PW [1] with the exception of presentation API, but we didn't bump that bundle version for reasons already discussed.
Note that master is already incompatible with Eclipse SDK 3.8, see bug 378000.
(In reply to comment #1) > AFAIK this was done because CTabFolder is different in 3.8 and 4.2 (different > implementation, different behaviour). And both impls of CTabFolder are contained in the same package and exported by the same bundle? (In reply to comment #4) > > For Platform/UI when we remained API compatible [1] but changed most of our > internal behaviour, we bumped our minor version to 100. So 3.100.0 would be > consistent with a change in behaviour. If it is API compatible then this is the route I would take for the SWT bundle version. AFAIK SWT does not version its packages so we are only talking about the bundle version, correct?
(In reply to comment #5) > Note that master is already incompatible with Eclipse SDK 3.8, see bug 378000. That looks like a transient build problem, it works fine for me with I20120429-2000 PW
(In reply to comment #7) > That looks like a transient build problem, it works fine for me with > I20120429-2000 > Sorry, my comment doesn't apply, it's the 3.8 build with SWT from master. PW
Just to give some context, part of SWT has been effectively split stream for most of the development of the 4.x stream. To avoid the pain of having two different streams of SWT, the 4.x version of CTabFolder was maintained in an e4 repository for most of this time. The SWT team wanted to wait as long as possible to minimize the amount of time they needed to maintain two streams. With the final milestone coming up they decided to finally make the split and merge the 4.x CTabFolder into the SWT repository where it belongs (it would have happened earlier in M7 if we had working builds). This leaves only a month or so where they need to port fixes across two streams. They now have 3_8_maintenance for any final fixes needed in the 3.x stream, and master for 4.x development. They are going to use Paul's script to confirm that commits are made in both streams where applicable. My understanding was that 4.x CTabFolder was API compatible with 3.x CTabFolder. Bogdan can you confirm that? The 4.x copy of CTabFolder definitely has new API so we'll need to have a PMC discussion about that.
(In reply to comment #9) Thanks. But if the new CTabFolder is backwards compatible, then I still don't see why the split is needed. Since 4.2 is declared our "primary" build, the implementation must be ready for prime time, so it can just as well go into 3.8.
While the new CTabFolder is API compatible with the 3.8 version, there are some behavioral changes. For this reason, we incremented the version of all SWT projects in the master (4.2) stream to 3.100 to reflect these changes. The main changes in behavior are: native toolbar buttons (for min, max, chevron) and in the handling of top right control wrapping. With the 3.8 CTabFolder, users were expected to handle overflow wrapping of the top right control, in 4.2 they get this for free. The new version of CTabFolder will work with 3.8.x plugins if they take into account these new behavior changes (mainly not trying to do the layout of the top right control when wrapped) - hence the version increment. Otherwise the 3.8 version of CTabFolder will continue to work for them. Marking as FIXED.
> behavioral changes. For this reason, we incremented the version of all SWT > projects in the master (4.2) stream to 3.100 to reflect these changes. Please use a higher minor number (e.g. 900). 3.100.x should be used in the upcoming maintenance branch for 3.8. We need to make sure that 4.x versions are always higher than 3.x ones.
(In reply to comment #12) > Please use a higher minor number (e.g. 900). 3.100.x should be used in the > upcoming maintenance branch for 3.8. We need to make sure that 4.x versions are > always higher than 3.x ones. If API was added in the R3_8_maintenance branch, swt would go to 3.9.0. There's a long way to go before catching up with 3.100.0, isn't that sufficient? PW
(In reply to comment #13) > (In reply to comment #12) > > Please use a higher minor number (e.g. 900). 3.100.x should be used in the > > upcoming maintenance branch for 3.8. We need to make sure that 4.x versions are > > always higher than 3.x ones. > > If API was added in the R3_8_maintenance branch, swt would go to 3.9.0. It's not just about API as normally we don't add API in the maintenance branch anyway. Also, it's not yet 100% decided that there is no 3.9 release. Actually my statement "3.100.x should be used in the upcoming maintenance branch for 3.8" was wrong. This would be used for implementation (non-API) changes in a possible 3.9 stream. The maintenance stream would get 3.8.1.x. > There's a long way to go before catching up with 3.100.0, isn't that > sufficient? In theory yes, but the version numbering guidelines are pretty clear about this: each new release needs +100 in the service segment and +1 for maintenance releases (if no API was added).
(In reply to comment #12) > > behavioral changes. For this reason, we incremented the version of all SWT > > projects in the master (4.2) stream to 3.100 to reflect these changes. > > Please use a higher minor number (e.g. 900). 3.100.x should be used in the > upcoming maintenance branch for 3.8. We need to make sure that 4.x versions are > always higher than 3.x ones. I think there is just a misunderstanding here on the segment we are talking about. If SWT had fixes in a 3.8 maintenance branch it would use 3.8.100, not 3.100.x. In 4.x we have a scenario that is not discussed in the versioning guidelines at all. Since there could be further API additions in 3.x, we need to add 100 to the *minor* segment in the 4.x stream. Typically we just add 100 in the *service* segment to allow for non-API fixes in the maintenance stream. This is how it would play out if we hypothetically had a 3.9 release: Eclipse 3.8: SWT 3.8.0 Eclipse 4.2: SWT 3.100.0 Eclipse 3.8.1: SWT 3.8.1 Eclipse 3.9: SWT 3.9 (or 3.8.100 if it didn't add any API) Eclipse 4.3: SWT 3.101.0.
> I think there is just a misunderstanding here on the segment we are talking > about. If SWT had fixes in a 3.8 maintenance branch it would use 3.8.100, not > 3.100.x. Ah, OK. Yes, that would work.
(In reply to comment #15) > This is how it would play out if we hypothetically had a 3.9 release: > > Eclipse 3.8: SWT 3.8.0 > Eclipse 4.2: SWT 3.100.0 > Eclipse 3.8.1: SWT 3.8.1 > Eclipse 3.9: SWT 3.9 (or 3.8.100 if it didn't add any API) > Eclipse 4.3: SWT 3.101.0. The drawback this has is in the case where new API is added to the 3.9 release. This would bump that SWT version to 3.9. Now a client depends on the new 3.9 API and uses the following range: [3.9, 4.0). This will include the Eclipse 4.2 version of SWT version 3.100.0 where the new API has not bee added (I presume it will be added in SWT version 3.101.0).
(In reply to comment #11) > While the new CTabFolder is API compatible with the 3.8 version, there are some > behavioral changes. OK, then the new version could be called "signature compatible", but it's not API compatible [1], unless it only breaks clients that use the old class in illegal ways. API includes specified behavior (or de-facto behavior if the specification was unusably terse). [1] http://wiki.eclipse.org/Evolving_Java-based_APIs#API_Prime_Directive Is it exceptionally hard to make the new CTabFolder API-compatible with the 3.8 version? Best would be an implementation that behaves like the old one, unless a style flag is passed that requests the new behavior. Or don't break any clients: Ship the new class with a new name like CTabFolder4 and deprecate CTabFolder. BTW: The Javadoc in the master branch doesn't look up-to-date, since it doesn't tell a word about these changes.
(In reply to comment #17) > The drawback this has is in the case where new API is added to the 3.9 release. > This would bump that SWT version to 3.9. Now a client depends on the new 3.9 > API and uses the following range: [3.9, 4.0). This will include the Eclipse > 4.2 version of SWT version 3.100.0 where the new API has not bee added (I > presume it will be added in SWT version 3.101.0). Hm.. that's true. I'm having trouble imagining a versioning scheme that could properly account for this (multiple parallel streams with ongoing API changes and clients wanting to specify ranges within either or both streams). The best answer is to avoid doing 3.9 ;)
(In reply to comment #18) > OK, then the new version could be called "signature compatible", but it's not > API compatible [1], unless it only breaks clients that use the old class in > illegal ways. API includes specified behavior (or de-facto behavior if the > specification was unusably terse). McQ, Silenio, Bogdan and I reviewed the CTabFolder behaviour changes in detail yesterday. Apart from the lateness of the change, the changes in CTabFolder between 3.x and 4.x are not out of line with other behaviour changes that happen in SWT in a typical development cycle. It would probably be fine to release the new version in both 3.8 and 4.2. The decision to avoid putting the change in 3.8 was mainly about being extremely conservative with changing 3.8, especially this late in the cycle. You could definitely argue that we should be just as conservative in 4.2 and create a separate copy of the class for the new version. This option was seriously considered. This would minimize disruption in the short term, but in the long term it would not help the community. The new CTabFolder can be styled via CSS, but if clients stayed on the old one they would not have this ability. 4.x applications would therefore not have the ability to consistently style CTabFolders across their application and the result would look inconsistent. Clients would need to manually port their code to use the new CTabFolder, and given there is no API change and only minor behaviour changes this is a lot of work to put on clients for little benefit.
(In reply to comment #9) > My understanding was that 4.x CTabFolder was API compatible with 3.x > CTabFolder. Bogdan can you confirm that? The 4.x copy of CTabFolder definitely > has new API so we'll need to have a PMC discussion about that. Just to clarify this comment, I was looking at the 4.x copy of CTabFolder *before* Bogdan and Silenio merged it back into org.eclipse.swt.custom. There were some new API methods in the 4.x copy, but these were deleted as part of their merge. There are no longer any added, removed, or changed API methods between the two copies.
(In reply to comment #19) > Hm.. that's true. I'm having trouble imagining a versioning scheme that could > properly account for this (multiple parallel streams with ongoing API changes > and clients wanting to specify ranges within either or both streams). The best > answer is to avoid doing 3.9 ;) Right, that is the key, parallel active streams that are adding API causes for version range nightmares. I have seen this issue before and there is not any good solution that I am aware of. It adds another dimension on to a version range where the provider of the version needs more control over what ranges it is valid to be contained in. For example, SWT version 3.100.0 wants to be included in any range that contains version 3.100.0 but it has an additional condition to be excluded from any range that has a floor (or left hand) value >= 3.9.0 && < 3.100.0 (e.g. [3.9, 4.0) or [3.10, 4.0) etc.). This is not something that can be expressed in the simple mathematical version range notation we use today.
So, to be clear on the conclusion here, there will be split streams, right? Different versions of SWT, and in some cases, people may want to adjust their pre-req ranges? I'm wondering if a cross-project list note would be in order to explain to others how to adjust their pre-req ranges? (or if/when they should or should not). I doubt would effect anyone directly on top of the IDE ... since presumably "the workbench" will pre-req exactly the right version, but seems it might effect some RCP apps or "stand alone" SWT apps? So, just encouraging the team to be clear on what is recommended to others (and, it is not clear to me what to recommend! :) Your choice, just asking the question.
You should at least document the behavioral changes and the things that should not be done on the version in master. Bug 378000 was real and other clients can run into similar issues. In addition to the Javadoc updates, this also needs to go into the porting guide.
I've opened Bug 378264 and Bug 378266 to track the javadoc and porting guide doc changes. We will also post on the cross-project list re: version numbers.
