Re: Project future.

On Tue, 2008-12-02 at 16:09 -0800, Mike Bowie wrote:
> Mauro C. wrote:
> > Hi to all,
> > 
> > During try to fix #737 #738 #631 #616 had a look inside many parts of net.sourceforge.phpeclipse
> > 
> > notice many things to do:
> > 
> > 1) Decide how to use subversion, work always on trunk or create branch for major release.
> > 2) Create a source copyright template.
> > 3) there are alot of nasty code, expecially inside parsers.
> > 4) Decide if we have to move to 100% AST.
> > 
> > 
> > Mauro Casciari
> > 
> 
> Mr C ;-)
> 
> 1) I believe the way subversion is being used currently generally 
> "correct", with major development changes being carried out on a branch 
> and then merged with (or replacing) trunk.  I think in this case there 
> might be advantages in not branching however... I think we could get 
> away with tagging releases and developing in trunk.  Perhaps someone 
> else can suggest what we stand to gain from branching before a release; 
> given the scale of the development team and the volume of commits.
> 
> 2) Good idea.
> 
> 3) Yes, yes there is.  I have noticed vast volumes of code which has 
> been commented out and left for dead; especially functions which are now 
> provided by Eclipse itself.  I've also found that a lot of the older 
> code lacks meaningful comments or in some case, any comments at all.  I 
> think we all stand to benefit from a few more in-line notes.
> 
> 4) I think the more we can leverage AST, the less heavy listing we'll be 
> doing on simple integration and the more time and effort we can focus on 
> other more complex features... it's also going to mean more serviceable 
> code; IMHO.
> 
> My $0.02 :-)
> 
> Mike.
> 
> 

Here are my thoughts on branching.

The reason i see it's important are in two areas.

1) Compatibility. Each release of PHPEclipse should reflect a specific
version of Eclipse. We had talked before about releasing a [major]
version with the Eclipse project release. Sometimes in the new releases
of Eclipse backwards compatibility with previous releases of Eclipse can
be broken. If we did development in trunk then we would need to make
code fragment features to fix the compatibility issue. I have mentioned
before the troubles i have had with this method, so i am bias.

2) Incomplete features. If mbowie and i are working on a big feature and
it's going to take some time we both commit to trunk to share our code.
Now say incastrix and scorphus have found a bug that is a major
annoyance. They both spend time tracking it down and fixing it. Now they
want to do a new release. So we tag trunk and make the release, but
there is the code in trunk that mbowie and ed_mann (me) have committed
and it's not complete. Either we need to keep track of these changes and
remove them before a build, or mbowie and i need to branch when we do
our work. Because our code was targeted for the next major release of
PHPEclipse; not a incremental release of our current production code, it
should not have been in the stable release.

3) code refactoring. As we move into refactoring the code and cleaning
it up, it may be a few days after a commit that the project will even
build. This could be due to many reasons, granted a few days is a long
time we should not go that long, but it may happen. If we did all our
work in trunk it would hamper our ability to release incremental patches
as needed, not knowing what state the project is in. And that the major
code change we did has not been tested.

It has been said that patching trunk with changes from branch is more
work, and i agree it's more work, but it's necessary work. This extra
step insures that when we release a version of PHPEclipse it's as stable
as we can make it at that point. 

My vote is for staying with branching. Simon is crying now so i must go.

Thanks everyone for your work.


------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/