Hi Martin,
Fine with me. I just hope that we settle on the Luna SR2 contribution question quickly so I can start doing some TM 4.0 work in master.
Best regards, Uwe
J
From: tm-dev-bounces@xxxxxxxxxxx [mailto:tm-dev-bounces@xxxxxxxxxxx]
On Behalf Of Oberhuber, Martin
Sent: Mittwoch, 21. Jänner 2015 15:13
To: TM project developer discussions
Subject: Re: [tm-dev] TM 3.7 M1
Hi all,
I have a proposal for resolving the issue on TM for Luna SR2.
Background on history:
-
In the past, the o.e.rse feature “included” the o.e.rse.terminals feature which “included” o.e.tm.terminal.
This tight coupling hurt us since we couldn’t update terminal while keeping rse unchanged.
Uwe’s change:
-
Uwe untangled o.e.rse from o.e.rse.terminals , making it possible to contribute different terminal implementations to RSE.
This is a good thing, and was done in response to Doug Schaefer’s concern that we have 3 different terminal views in Eclipse.
Proposal for Luna SR2:
-
Reinroduce an o.e.rse “requires” o.e.rse.terminals instead of the older “includes”, and make o.e.rse.terminals “require” tm.terminal instead of include.
This resolves our issue of the tight coupling, and is a minimal change compared to what we have now.
Adopters will get the same output as previously, but with dependencies weakened.
It should make the current TM master stream compatible with Luna SR2, so it can be released as 3.6.2.
It does NOT resolve Doug Schaefer’s request of reducing the # of terminal views. That will have to wait until Mars.
Does that sound acceptable for all ?
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools,
Wind River
direct +43.662.457915.85 fax +43.662.457915.6
The ask was for separating o.e.rse and o.e.rse.terminals, not for introducing another confusing feature.
Best regards, Uwe
J
Is there a reason why not let the existing feature include what was there before and introduce a newer slimmer feature instead of breaking existing setups in sr stream ?
My understanding is that in order to get exactly the same result, adopters of the o.e.rse feature have to take action now:
When they only included o.e.rse in a product so far and they want exactly the same result, they have to also include o.e.rse.terminals
now.
On the other hand, users who only “update” will have o.e.rse.terminals already (since it was previously “included”) and they would
not see a change due to the update.
If I am correct (Uwe can you confirm?) this is in fact an edge case though personally, I think making it rse 3.7 would be a better
signal to the adopter community.
IMO, making it 3.6.1 would imply that “everything works as before for everyone except bugs have been fixed”.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner
– Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
Hi Greg,
We separated out the o.e.rse.terminals feature from the o.e.rse feature. That’s more than bugfixing and should justify moving to
3.7, isn’t it?
Best regards, Uwe
J
This week is Luna SR2 RC1.
I have a question about the TM version. Changing the version from 3.6 to 3.7 implies a minor API change has been made, however I can’t see anything that looks like an API change. Can someone confirm that there
is an API change between 3.6 and 3.7? The reason this is important is that a 3.7 release will require a release review and this needs to be scheduled before the SR2 release. If this is only a bug fix release, then it should really be 3.6.1.
Well, that we cannot remove misleading and deprecated features from one release to another, that’s a shame. It’s not good that user
can still install these deprecated features. Hopefully, we can get rid of them in one of the next steps. At least, all deprecated but still visible features have now the marker “(Deprecated)” in their feature names.
@Greg: I’ve also attached an updated tm.b3aggrcon file. No removals, just additions and updates to the version ranges. Can you push
this one to the o.e.simrel.build repository for the Luna_maintenance branch please?
Thanks, Best regards, Uwe J
Thanks Greg. I think keeping the feature available is OK as long as the EPP packages don’t pull it in.
For the TM project, the key point was relaxing version constraints and dependencies to _make possible_ the removal / replacement
of terminal.
Next step will be with the EPP Packages to actually leverage the new flexibility and do the right thing.
Uwe is out of office at the moment so double thanks to you , Greg, for moving forward with this.
Martin Oberhuber, SMTS / Product Owner
– Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
I had to revert this change. Removing a feature (org.eclipse.tm.terminal.sdk) is more than a minor version increment as it has the potential to affect many upstream projects (PTP being one). We will need to leave
this in for the 3.7 release for Luna SR2. If we want to remove it in the future, it would need to be a 4.0 release in the Mars timeframe.
I've updated the Luna tm.b3aggrcon file, but I needed to use org.eclipse.tm.terminal.core.sdk rather than org.eclipse.tm.terminal.sdk. Can you check that it looks ok?
FYI, the RSE integration from the new TCF Terminals view is available in the meantime from the TCF nightly repository. I made some final adjustments
to the old RSE Terminals feature. Would be nice if you could update the TM 3.7 M1 milestone repository with the latest build from master.
From technical POV, the work on #440782 is done. All remaining is getting the contributions for the sim releases updated for both TM and TCF.
Thanks, Best regards, Uwe J
<tm.b3aggrcon>_______________________________________________
tm-dev mailing list
tm-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tm-dev
|
