Re: [vtp-dev] Project meta data is out of date fortechnology.voicetools

[<scott@xxxxxxxxxxxxxxxx>]

Out of the various SVN usage methods, at bluestone we use an 'unstable'
trunk and 'stable' branches.  This method is great for very fast
development speeds as well as a great product release cycle.  Everyone just
commits early and often to trunk, it almost doesn't matter if it's broken. 
Then as it gets towards release time, the trunk is fixed up as much as
possible for the release and then branched.  That new release branch is
only for the release, so therefore only bug fixes go in.  After the branch
is made, development on the trunk continues as well as bug fixes from the
branch are merged into the trunk.  The advantage of this method is that
each branch is a basically a throw away.  For example a quick fix can be
put into the branch but the better fix can be put into the trunk.  Once the
next release is done, that old quick fix is never seen again.

Each SVN method stems from what your goals are.  If your goals aren't the
same, then this method may not be the best.

Scott

On Tue, 08 Jan 2008 16:54:15 -0600, Trip Gilman <trip@xxxxxxxxxxxxxxx>
wrote:
> We've got our new SVN repository.  I'll be transferring the code base
over
> this week.  My initial idea is to have the plugins divided up into groups
> based on usage, such as one group being devoted to the runtime and
another
> to the GUI designer functionality.
> 
> Also, branches will be created at the project root instead of under
> individual plugins.  In SVN, branches are cheap copies and the merging
> capabilities are improved over CVS, so this approach won't add much
> overhead
> to the development process.
> 
> I'll update the 1.0 release information in the portal and schedule a
> tentative release for Q2 this year for the integrated 3.0 release.  The
> 2.0
> release was pretty much indefinitely postponed due to delay in the IP
> process, but will be available within the repository for those interested
> in
> it.
> 
> If anyone has any thoughts on branching schemes or development
> organization
> I'm all ears.  I'd like to find a process that will work for all of us.
> 
> Trip Gilman
> 
> 
> On 1/8/08 3:47 PM, "portal on behalf of emo" <emo@xxxxxxxxxxx> wrote:
> 
>> Projects are required to keep meta data up to date using the
> MyFoundation
>> Portal (http://portal.eclipse.org/).  The following problems were found
>> with this project's meta-data:
>>
>> * The date for release 1.0 is in the past, but the release is not
>> completed. If it is completed, it should be marked as completed; if it
> has
>> been postponed, it should be given a new target date.
>> * There is no next/future release of this project. All Eclipse projects
>> must have a "next release" planned and scheduled.
>> _______________________________________________
>> vtp-dev mailing list
>> vtp-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/vtp-dev
> 
> _______________________________________________
> vtp-dev mailing list
> vtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/vtp-dev