Community
Participate
Working Groups
In order to prepare for TCF 1.0 release, I'm planning to make following changes in TCF source code repositories: 1. Create branch 1.0.0 In the branch: 2. Change version number from 0.*.* to 1.0.0 in the source files. 3. Remove "Incubation" in plugin descriptions. Since TCF is not a sub-project of Target Management anymore: 4. Rename Java packages: org.eclipse.tm.tcf.* -> org.eclipse.tcf.* 5. Rename plugins: org.eclipse.tm.tcf.* -> org.eclipse.tcf.* In order to resolve existing and potential header file naming conflicts: 6. Rename TCF agent .h and .c file to include "tcf" as first directory name in the file path. 7. Change #include directives in .c files to start with "tcf", e.g.: "#include <config.h>" -> "#include <tcf/config.h>" After all refactoring is done, current master branch will be renamed to 0.6.0, and new master will start from 1.0.0. Comments are welcome.
By TCF 1.0, I assume you're talking about June's Juno release. Also, we should be careful about calling things 0.6 and such. We are not allowed to release second digit versions without a legal review. I'd like to avoid that if possible. As such, why not just do all this on master and skip a 0.6 thing.
(In reply to comment #1) > By TCF 1.0, I assume you're talking about June's Juno release. Yes. I'd like to start working on it now to have plenty of time for discussions, testing, legal review, etc. > Also, we should > be careful about calling things 0.6 and such. We are not allowed to release > second digit versions without a legal review. I'd like to avoid that if > possible. I'm not proposing to have an official 0.6 release. But we need a name (or tag) for the code before the 1.0 refactoring. 0.6 seems reasonable for me, but we could call it pre-1.0 or something, except in C code the version has to be a number. > As such, why not just do all this on master and skip a 0.6 thing. The planned changes are rather extensive. They can make the code unusable for downstream projects for some time. Branching would make transition to 1.0 much easier for them.
(In reply to comment #2) > (In reply to comment #1) > > By TCF 1.0, I assume you're talking about June's Juno release. > > Yes. I'd like to start working on it now to have plenty of time for > discussions, testing, legal review, etc. Excellent. Just checking :). > > Also, we should > > be careful about calling things 0.6 and such. We are not allowed to release > > second digit versions without a legal review. I'd like to avoid that if > > possible. > > I'm not proposing to have an official 0.6 release. But we need a name (or tag) > for the code before the 1.0 refactoring. 0.6 seems reasonable for me, but we > could call it pre-1.0 or something, except in C code the version has to be a > number. OK, it's just that generally branches named with a version number are meant for maintenance of that release. All work towards the next release is either done on master or on a side branch intended to be merged in to master when ready. We can tag just before the merge (or just write down the commit id.) if necessary. > > As such, why not just do all this on master and skip a 0.6 thing. > > The planned changes are rather extensive. They can make the code unusable for > downstream projects for some time. Branching would make transition to 1.0 much > easier for them. That's fine, but as I mentioned, you should do that on a side branch, not called 1.0 since we'll use that for the name of the maintenance branch we create after the Juno release. Also what is your plan for changes made to master during this? Are you planning on propagating them all, or are you planning on doing a merge later. That wasn't clear in your original post.
(In reply to comment #3) ... > > > As such, why not just do all this on master and skip a 0.6 thing. > > > > The planned changes are rather extensive. They can make the code unusable for > > downstream projects for some time. Branching would make transition to 1.0 much > > easier for them. > > That's fine, but as I mentioned, you should do that on a side branch, not > called 1.0 since we'll use that for the name of the maintenance branch we > create after the Juno release. Yes, I want to do it on a side branch. If name 1.0.0 is confusing, I can call it juno-refactoring or whatever. But it is important to decide what version number we put into the source code in that branch. And I think it has to be 1.0.0. It would be good if the branch name reflects that fact. > > Also what is your plan for changes made to master during this? Are you planning > on propagating them all, or are you planning on doing a merge later. That > wasn't clear in your original post. I'd like to reduce changes in master to a minimum to make merging easier. Changes in master will be merged periodically into the refactoring branch. When we decide that refactoring is completed, I suggest we simply rename master to 0.6 (or something), and rename the refactoring branch to master. It is very easy to rename a branch in git. The idea is that downstream project can continue to build binaries from master without being disturbed by the refactoring until it is all done, and even after that (by switching to 0.6) - until they decide to upgrade. Note that we do not release agent binaries, so, at least, the agent is built by downstream, so we have to make sure those builds are not broken during the refactoring.
(In reply to comment #4) > Yes, I want to do it on a side branch. If name 1.0.0 is confusing, I can call > it juno-refactoring or whatever. But it is important to decide what version > number we put into the source code in that branch. And I think it has to be > 1.0.0. It would be good if the branch name reflects that fact. Well, no, what if we had two side branches for 1.0 work? Name the branch after what you're doing there. You can put whatever number you want in the code. > I'd like to reduce changes in master to a minimum to make merging easier. > Changes in master will be merged periodically into the refactoring branch. When > we decide that refactoring is completed, I suggest we simply rename master to > 0.6 (or something), and rename the refactoring branch to master. It is very > easy to rename a branch in git. Renaming branches is painful for remotes. I highly suggest you don't do that. Sounds like you're set up to merge your side branch cleanly back to master. That's the standard workflow I see people using. It's what I suggest. We can tag the commit just before the merge if people need it. You wouldn't even need to create a branch for it until someone wants a change against it, and hopefully that won't happen.
(In reply to comment #5) > (In reply to comment #4) > > Yes, I want to do it on a side branch. If name 1.0.0 is confusing, I can call > > it juno-refactoring or whatever. But it is important to decide what version > > number we put into the source code in that branch. And I think it has to be > > 1.0.0. It would be good if the branch name reflects that fact. > > Well, no, what if we had two side branches for 1.0 work? Name the branch after > what you're doing there. You can put whatever number you want in the code. > > > I'd like to reduce changes in master to a minimum to make merging easier. > > Changes in master will be merged periodically into the refactoring branch. When > > we decide that refactoring is completed, I suggest we simply rename master to > > 0.6 (or something), and rename the refactoring branch to master. It is very > > easy to rename a branch in git. > > Renaming branches is painful for remotes. I highly suggest you don't do that. > > Sounds like you're set up to merge your side branch cleanly back to master. > That's the standard workflow I see people using. It's what I suggest. > > We can tag the commit just before the merge if people need it. You wouldn't > even need to create a branch for it until someone wants a change against it, > and hopefully that won't happen. OK. To summarize it: 1. I'll create "juno-refactoring" branch and we will use it to work on TCF 1.0 2. I'll merge "master" into "juno-refactoring" periodically. I expect "master" to be dormant and most development to be done in "juno-refactoring". 3. When we are ready, we tag "master" (and branch it if needed), then we will merge "juno-refactoring" into "master". I still think that #3 can be done easier and cleaner by some simple branch labels manipulation in git, but we don't really need to decide it now. We can experiment with that when it's time to merge. How about #3...#7 of the refactoring plan? Any comments on that?
Actually, you should send this out to the tcf-dev mailing list. Especially Uwe should have his say in what's going on here since he's doing a lot of development at the moment.
OK with what has been proposed in all previous comments. Just as a kind of "foot note": >Since TCF is not a sub-project of Target Management anymore: > >4. Rename Java packages: org.eclipse.tm.tcf.* -> org.eclipse.tcf.* >5. Rename plugins: org.eclipse.tm.tcf.* -> org.eclipse.tcf.* Obviously this will heavily effect all the Target Explorer plugins + features as we have dependencies to the TCF core plug-ins all over the place. The question is if we will update the dependencies of TE to TCF in the branch too before merging the branch back to master so that master is buildable for both TE and TCF after the merge? Or is it acceptable to have master not buildable for TE for a short while after the merge? And if TCF is eliminating the ".tm." from it's plug-in names, shouldn't the same happen for the TE than too?? All of the TE plug-ins starts with "org.eclipse.tm.*" for consistency with the TCF core plug-ins. I mean I don't have a strong opinion on keeping or dropping the ".tm." fragment from the (TE) plug-in and package names, but having a consistent guideline on plug-in names wouldn't hurt.
(In reply to comment #8) > OK with what has been proposed in all previous comments. Just as a kind of > "foot note": OK. I have created "juno-refactoring" and made first round of the refactoring. Please, have a look. > > >Since TCF is not a sub-project of Target Management anymore: > > > >4. Rename Java packages: org.eclipse.tm.tcf.* -> org.eclipse.tcf.* > >5. Rename plugins: org.eclipse.tm.tcf.* -> org.eclipse.tcf.* > > Obviously this will heavily effect all the Target Explorer plugins + features > as we have dependencies to the TCF core plug-ins all over the place. The > question is if we will update the dependencies of TE to TCF in the branch too > before merging the branch back to master so that master is buildable for both > TE and TCF after the merge? Or is it acceptable to have master not buildable > for TE for a short while after the merge? I'd like you to switch to "juno-refactoring" for ongoing TE development. TE code is fully buildable there - I have fixed TCF import everywhere, including TE code. If you switch, you will need to re-import TCF plugins into the workspace, because TCF plugin names have changed. > > And if TCF is eliminating the ".tm." from it's plug-in names, shouldn't the > same happen for the TE than too?? All of the TE plug-ins starts with > "org.eclipse.tm.*" for consistency with the TCF core plug-ins. I mean I don't > have a strong opinion on keeping or dropping the ".tm." fragment from the (TE) > plug-in and package names, but having a consistent guideline on plug-in names > wouldn't hurt. As I understand, current official status of the TE code is a component of the TCF project. So correct name is org.eclipse.tcf.te. Doug, could you confirm/clarify this?
(In reply to comment #9) > As I understand, current official status of the TE code is a component of the > TCF project. So correct name is org.eclipse.tcf.te. Doug, could you > confirm/clarify this? Yes. Actually in retrospect, TE should never have used TM since it was added after TCF moved to CDT. But that's why JDT has such great refactoring tools :).
(In reply to comment #10) > (In reply to comment #9) > > As I understand, current official status of the TE code is a component of the > > TCF project. So correct name is org.eclipse.tcf.te. Doug, could you > > confirm/clarify this? > > Yes. Actually in retrospect, TE should never have used TM since it was added > after TCF moved to CDT. But that's why JDT has such great refactoring tools :). and hopefully GIT can cope with such refactroings and the history does not get lost....
(In reply to comment #9) > I'd like you to switch to "juno-refactoring" for ongoing TE development. TE > code is fully buildable there - I have fixed TCF import everywhere, including > TE code. If you switch, you will need to re-import TCF plugins into the > workspace, because TCF plugin names have changed. OK. I'll switch to the "juno-refactoring" branch for active development later this week. Don't want to destabilize the demo for tomorrows review. I'll merge the minor changes being pushed to master to the branch after having switched. (In reply to comment #10) >> As I understand, current official status of the TE code is a component of the >> TCF project. So correct name is org.eclipse.tcf.te. Doug, could you >> confirm/clarify this? > >Yes. Actually in retrospect, TE should never have used TM since it was added >after TCF moved to CDT. But that's why JDT has such great refactoring tools :). No problem. I'll do the renaming for the TE plug-in's after having switched to the branch. (In reply to comment #11) >and hopefully GIT can cope with such refactroings and the history does not get >lost.... Git is having a change based history. You cannot loose it by renaming the objects contained in a change :).
- Target Explorer active development switching to "juno-refactoring" branch: DONE - Target Explorer namespace change to "org.eclipse.tcf.te.*": DONE :)
As part of the refactoring, I'm reviewing public APIs exported from the core TCF plugins. At the moment I'm concerned about "Export-Package: org.eclipse.tcf.extensions" in org.eclipse.tcf. The package provides abstract extension point manager implementation. I feel that TCF core plugins should not commit to providing extension point management abstraction - it is way outside of the project scope. I'm going to make the package internal. Please, comment if you have any objections.
(In reply to comment #14) No objection to make it internal. If you like, we can rewrite the services provider extension point reader to get rid of those classes all together and remove the "extensions" package from the "org.eclipse.tcf" plug-in.
It is time to merge juno-refactoring code (TCF 1.0) into the master branch in the TCF repository and close this bug. I'm planing to do the merge next week, probably next Tuesday. Please, comment if you have any concerns or questions.
The merge is completed. This concludes code refactoring for version 1.0. "master" branch now contains the latest TCF code. "juno-refactoring" should not be used any more.
