Hi Richard, I would second Tom's position... Knowing the amount of changes to be done, even if they are quite co-located, I am also in favor of a branch...
Just my 2 cents, keep your branch in sync as much as possible... Maybe we could also delay other major work about restructuring if any is pending... but since we just released, I would guess that we are at a good point for you to branch for a couple of weeks. Best regards, Olivier Gruber, Ph.D. Persistent & Distributed Object Platforms and Frameworks IBM TJ Watson Research Center "If at first the idea is not absurd, then there is no hope for it." Albert Einstein "Richard S. Hall" <[EMAIL PROTECTED]> 12/18/2006 07:01 PM Please respond to felix-dev@incubator.apache.org To felix-dev@incubator.apache.org cc Subject Re: Branch or not? Thomas Watson wrote: > 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. > Well, by that standard, I would have to do a temporary branch, since I could not guarantee only a few days of breakage... As I said originally, I was leaning toward a temporary branch... I can probably minimize some of the branching by doing as much as I can in trunk. I could even do the work side by side using a different file, but at that point it seems like I might as well branch. Thanks for the input, Tom. > Tom (that Equinox guy) > Shouldn't that be, "that other Equinox guy" ? ;-) -> richard > > > > > "Richard S. Hall" <[EMAIL PROTECTED]> > 12/18/2006 09:09 AM > Please respond to > felix-dev@incubator.apache.org > > > To > felix-dev@incubator.apache.org > cc > > Subject > 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 >> > quality. > > 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 > > >
