Major changes to EPIC's internals - branch?

jploski wrote on Sat Nov 26 21:31:18 CET 2005:

Dear EPIC developers,

Let me inaugurate this forum with an administrative question:

Should I create a new branch in CVS for my next large commit or should it
all go into HEAD (aka "testing")?

Background:

I have made significant changes to EPIC's internals in my private copy,
dropping the dependency on cbg.editor entirely and introducing a strong
new dependency on ANTLR.

The reason for these changes was my wish for better performance and reliability.
Indeed, most of the reported syntax highlighting bugs no longer exist in
my current version and the editor opens several times faster on a large
file. I am now getting the major old features (outline, folding) working
(also faster and more reliably).

On the other hand, the scope of changes I have made inevitably means that
there will be new bugs included. Furthermore, I am concerned about maintainability
because to understand the new code, one has to learn ANTLR (as I did to
write it; it's certainly not very pretty). Contrast this with the need to
know modified jEdit rules file syntax and cbg.editor's internals for the
previous version.

Personally, I don't think branching is a good idea. Maybe I should have
done it when I set out with my current work, but I guess doing it now would
cause confusion as to which version of EPIC should attract new features
or fixes. Having invested quite some effort into the new one, I know that
I am not going to keep the previous version up-to-date myself.

To branch or not to branch - what is your opinion?

Regards -
JPL

jgangemi wrote on Thu Aug  3 17:12:09 MEST 2006:

i don't see anything wrong w/ having a private branch that you use to develop
new features that then gets merged down to the main development branch.

the dependency on ANTLR maybe a foregone conclusion if we want to be able
to parse the perl code - unless we want to investigate using PPI (i came
across this article yesterday and it mentions an epic developer contacted
the author in the comments; http://www.perl.com/pub/a/2005/06/09/ppi.html)
to try and parse the perl code as well.

i think this is ok provided the integration w/ antlr is hidden from the
rest of the epic implementation (this basically would require wrapping the
antlr impl, but that already goes on in the code).