[kepler-dev] Re: [SDM-SPA] RFC new directory structure

[Vouk]

I like Matt's branching and notational model.
Mladen

Matt Jones wrote:

> Some more build comments, follwoing on my earlier comments:
>
> Xiaowen Xin wrote:
>
>> Hi Mladen,
>>
>> Actually, right now, new development goes into src/ just like all other
>> source code.  As long as it compiles and it doesn't disrupt other
>> people's classes, it's allowed in src/.  But of course this wouldn't
>> work for the few days/weeks leading up to the release.  We should
>> probably have a code freeze for a period of time before the release so
>> that we can all test it and make sure it works.
>>
>> I think the best way to deal with this is to have branches in CVS.  I
>> believe this is how most major projects do it.  So we could have a
>> stable branch, from which we would make a release.  In addition, we
>> would have a development branch where untested code will go.
>
> Agreed. This reiterates my emails from earlier.
>
>>
>> So we don't need development directories.  We just need a development
>> branch in CVS.
>
> I prefer to model the tree as a semi-stable development version, with 
> branches added for 1) highly experimental work, and 2) releases as 
> they are stabilized, and 3) patches to those releases.  This allows 
> development to continue while the release is debugged.  Here's an 
> example tree CVS revision tree for one file:
>
>                           KEPLER-1_0_0_BRANCH             KEPLER-1_0_0
>                        -- 1.3.0.1 -- 1.3.0.2 -- 1.3.0.3 -- 1.3.0.4
>                       /
> 1.0 -- 1.1 -- 1.2 -- 1.3 -- 1.4 -- 1.5 -- 1.6 -- 1.7 --1.8
>                              \
>                              EXP_FEATURE1_BRANCH
>                               -- 1.4.0.1 -- 1.4.0.2 -- 1.4.0.3
>
> Of course, this model requires that both the release bug fixes (e.g., 
> from 1.3.0.4) and experimental features (from 1.4.0.3) must be merged 
> into the HEAD when they are finished, else they be lost from the tree. 
> The alternative (of having separate development branches) requires 
> many more merge operations, which are hard.  So, I think this is the 
> most stable model for developers, because it keeps the development 
> tree on the trunk.  There are a number of treatises on the web about 
> how to use CVS in a team environment, and this is a common (maybe even 
> preferred) model for shared code repositories to minimize merging 
> while maximizing stability.
>
>
>>
>> While we're on the topic, Zhengang has suggested that we outline a
>> release schedule and goals for our next release.  I think that's a great
>> idea because I personally would really like to see a release soon to
>> give to Matt.  So any suggestions/proposals? =)
>
>
> Me too.  I already proposed a schedule in one of my earlier emails, 
> but got no responses from anyone.  My target milestones are listed in 
> Bugzilla for Kepler.  Any problems with that schedule?
>
>>
>> Regarding jar files in lib/, yes you're right, we didn't discuss
>> dividing that up by subproject.  Do you see a need to?
>
> No.
>
>>
>> This is also true for bin/, which at the moment isn't a problem because
>> we have only two files to put in there: runVergil.sh and runVergil.bat.
>
> No need for bin.
>
> Matt
>
>>
>> Xiaowen
>>
>> On Wed, 2004-03-17 at 15:37, Vouk wrote:
>>
>>> Xiaowen,
>>> Where does new development go, and stuff in progress?
>>> Programmer X works on item Z. Does not
>>> finish it that day, goes home.
>>>
>>> Normally, I would say, put it into a development
>>> archive (shared nevertheless and put a lock on it),
>>> but do not leave it on your machine, the latter may
>>> not exist in the morning.
>>>
>>> Do you plan to have development directories
>>> (or are we just discussing integrated release level codes?)
>>>
>>> It also looks like the jar and lib files will be a mixture
>>> of project-specific and shared items (according to
>>> the sctructure below). Is that true or am I misreading it?
>>> Same for bins etc.
>>> ?
>>> Thanks
>>> Mladen
>>
>>
>>
>>
>> _______________________________________________
>> kepler-dev mailing list
>> kepler-dev at ecoinformatics.org
>> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>
>