felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Watson <tjwat...@us.ibm.com>
Subject Re: Branch or not?
Date Mon, 18 Dec 2006 17:41:09 GMT
Advise from me on this topic seems a bit strange but I will give it anyway 
since I have gone through this type of change to the Equinox Framework 
many times ;-)

In general we (Equinox) like to do all future development directly in the 
HEAD because that is thought of as the latest and greatest.  For most 
situations this is perfectly acceptable.  But there are times where we 
need to make major enhancements and code restructure.  Since the OSGi 
Framework sits at the bottom of everything it can become very disruptive 
to make ongoing major changes to the HEAD while developing the new 
feature.  For these situations we usually favor a temporary branch where 
we can finalize the code without worrying about breaking the world that 
uses the code from HEAD.  This way we can save our code while we work out 
the details and then do a final commit to HEAD once it is ready.  We 
usually do not like to work in a temporary branch for more than a couple 
of weeks to reduce the amount of merging.  We do nightly builds from HEAD 
and usually like the builds to be somewhat usable.  It is not acceptable 
for us to go more than a few days with broken code in a N-Build.  This 
means our code in HEAD cannot remain half-baked for long periods of time 
(> 3 days would be unacceptable).  Not sure if any of this can be applied 
to Felix, but thought I would share my point of view.  To me it all 
depends on how many developers use the code from your main code stream.

Tom (that Equinox guy)

"Richard S. Hall" <heavy@ungoverned.org> 
12/18/2006 09:09 AM
Please respond to


Re: Branch or not?

Marcel Offermans wrote:
> I agree with Felix and Karl to do the changes in HEAD now. Of course, 
> you should always commit code that at least compiles, but HEAD is 
> meant for development, not for taking daily snapshots of release 

Well, I would expect all changes to compile, since it is doubtful I will 
commit something that wouldn't compile. I was more thinking about 
breaking existing functionality. The overall time frame could be a 
couple of weeks from when I start, depending on how much time I have to 
focus on it.

I can always hold off committing until I have it mostly working, but I 
wanted to try to avoid the "big bang" approach.

> We should define the goals for the next release (assigning JIRA issues 
> to the next milestone) and then start working on them.

Agreed. We did that for the 0.8.0 release and we have already started 
for the 1.0.0 release. For me, we have two main targets for 1.0.0:

   1. Require-Bundle
   2. Security

I will add require-bundle to the 1.0.0 release in JIRA...I will let Karl 
look at the security-related JIRA issues and add the ones that he thinks 
are appropriate.

Other people should speak up if they want to voice an opinion about 
specific issues that we should address and/or chip in.

-> richard

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message