Hi Greg,
Please keep it 3.7.0. We have the branch already named, TM_3.7_maintenance.
Best regards, Uwe
J
From: tm-dev-bounces@xxxxxxxxxxx [mailto:tm-dev-bounces@xxxxxxxxxxx]
On Behalf Of Greg Watson
Sent: Montag, 26. Jänner 2015 23:13
To: TM project developer discussions
Subject: Re: [tm-dev] TM 3.7 M1
Ok, I wasn’t aware that that this isn’t a new feature, so this could definitely be a 3.6.x release.
What do people wish to do?
I have no strong feelings either way. For a 3.7.0 release, the IP log has been approved and we’re just awaiting PMC approval for the release, so I don’t think this will be a problem.
Greg
Just one little nitpick, the o.e.rse.terminal feature is not new. It’s just modified, changing “includes” to “requires”.
IMO this could also be released as TM 3.6.2
but releasing as TM 3.7 is maybe a better message to the Community (since it is a small structural change, and this release is planned to be the last one).
Any update on creating a new Git repo for the TM 4.0 work (to hold the new terminals view, o.e.remote and related) ?
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind
River
direct +43.662.457915.85 fax +43.662.457915.6
Martin’s suggestion sounds like a good one provided downstream adopters see the same set of features they see now. If this is the case, I’m happy to go ahead. It’s RC1 this week, so is someone able to update the features so we can start
testing this asap?
For Luna SR2, I think we have to keep the rest of RSE for the same reason we have to keep the o.e.rse feature the same.
To summarize the Luna SR2 plan:
- include the new o.e.rse.terminal feature
- remaining content will be the same
We will still need a release review for the minor version increment, which I’ll get underway as soon as there is agreement on the plan.
For Mars, there does seem to be interest in supporting RSE at some level. Also, Rob’s comments regarding migrating to a replacement are valid, as it seems unlikely that it will be fully completed in the Mars timeframe. As a consequence,
I would be ok with keeping RSE in the Mars release, but marked as deprecated.
To summarize the Mars plan:
- remove o.e.rse.terminals from o.e.rse
- include o.e.remote and the other components
- mark o.e.rse as deprecated
Let me know if there are any objections to this strategy.
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.
I have a proposal for resolving the issue on TM for Luna SR2.
- 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
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.
- 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 ?
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.
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”.
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind
River
direct +43.662.457915.85 fax +43.662.457915.6
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?
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-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
|