Open GoogleCodeExporter opened 9 years ago
To level-set, I ran the tests against 3.5 a few weeks back and, amazingly, they
passed! The question this provokes is whether we want to do a port/branch at
all.
I've groused about maintaining branches elsewhere
(http://code.google.com/p/wt-commons/source/detail?r=214) and moving forward
I'd like
to think hard before we do another branch.
Original comment by phil.qui...@gmail.com
on 7 May 2009 at 9:05
Upping the priority since this should really get resolved before Eclipse 3.5
ships.
Original comment by phil.qui...@gmail.com
on 7 May 2009 at 9:07
"One source to rule them all, one source to find them, one source to bring them
all
and in the darkness bind them..."
After back-porting a host of minor fixes to the 3.3 branch, I'm really keen to
reconsider our branching strategy. The rub is I'm not seeing a deep reason for
distinct branches. The differences between the 3.3 and 3.4 branches are not
substantial and are GREATLY outweighed by the similarities. Moreover, there
are no
places where pre-processing or reflection would be required in a merge.
Finally,
moving forward, the fact that the 3.4 helper tests ran green out of the box for
3.5
only strengthens my conviction.
Certainly some thought would have to go into handling cases where new helper
functionality is not relevant for old Eclipse platforms. In the simplest case I
think documentation will suffice. In case new additions require references to
bits
that don't exist in earlier eclipse versions we could consider extracting these
dependent pieces out into fragments but we can cross that bridge when we get to
it.
I'm sure there's more to consider but this is where I'm at after nearly going
blind
staring at the diff/merge editor.
Original comment by phil.qui...@gmail.com
on 7 May 2009 at 10:41
Original comment by phil.qui...@gmail.com
on 8 May 2009 at 10:33
r229 wraps up the first cut of a merge. I chose to do this in the 3.4 branch
for
simplicity (and to preserve SVN revision history). Ultimately I'd like to do
away
with the eclipse33 and eclipse34 subdirectories and move the merged branch
somewhere
else. (We can certainly archive 33 if you want to keep it around during the
transition; just let me know about that.) Anyway, anticipating a likely need to
branch for e4 we might consider something like:
helpers/e3/...
The tests ran green for me on 3.3 and 3.4 so I feel good about this first cut.
If
you want to review the revisions you'll see how little conditional logic there
was in
the end.
Original comment by phil.qui...@gmail.com
on 11 May 2009 at 8:49
Cool!
RE: eclipse33. I can still see a use for them down the line -- Let's go ahead
and
nuke eclipse33 and eclipse34 trees and create /trunk/helper-libs/eclipse/. In
this
directory we can put plugins/ and features/. When/if we need fragments, they
can be
put into /trunk/helper-libs/eclipse33/. What do you think?
Original comment by jhouston.mail@gmail.com
on 11 May 2009 at 9:31
Sounds great.
I moved the eclipse34/ branch to eclipse/. I'll leave eclipse33 alone for now
in
case you want to do any sanity checking of the merge. Feel free to blitz when
you
feel comfortable (or give me the word and I will).
Original comment by phil.qui...@gmail.com
on 11 May 2009 at 10:55
Looks good. Can you go ahead and delete eclipse33?
Original comment by jhouston.mail@gmail.com
on 14 May 2009 at 1:05
Original issue reported on code.google.com by
phil.qui...@gmail.com
on 2 Apr 2009 at 10:09