[Vtigercrm-developers] 5.0.1, 5.1 releases

[Richie]

Well, my thought process is something like this :- 
 
I am sure some of you are working on your own branches and would like some features to be made part of the trunk. I had in mind that these specific contributions could be accomodated in 5.1 ie these can be made part of the 5.1 release. 
 
Does this make sense? Kindly let me know lest I go way overboard with svn fundas. 
 
Richie




---- Sergio A. Kessler<sergiokessler at gmail.com> wrote ---- 

  now one question: do you really need to branch 5.0.1 ?

or put it another way: do you already have code for 5.1 that will
*not* go in 5.0.1 ??

if the response is "not yet", then the 5.0.1 branching is unnecesary
for now, IMO...


remember: branch iif you MUST.

/sak

On 9/20/06, don <don at vtiger.com> wrote:
>
>
> Hi all,
>
> Thanks for all your valuable feedbacks and suggestions.
>
> From looking into your inputs we also feel the
> maintaining a separate 5.1 branch is unnecessary
> and will be
> cumbersome. So we will be doing the feature
> additions for 5.1 in the top of the trunk.
>
> We will have only the 5.0.1 branch for bug fixing. All
> fixing done in this branch will also be merged in
> the top of th trunk.
>
> Kindly let us know your opinions on this.
>
> Thanks,
> Don
>
>
>
>
> ---- On Tue, 19 Sep 2006 Jens Hamisch <jens at strawberry.com>
> wrote ----
>
>
> Hi,
>
> I've got some experience with large software development
> projects which all had two things in common:
>
> * A hughe number of developers
> * At least more than one 'official' release handed over
> to customers.
>
> Thus a version management was obligatory for all of those
> projects. The systems used were varying from one project
> to another: SCCS, RCS, CVS, ClearCase, ...
>
> All of thoses systems had their pro's and con's.
> The common
> things were the ability to branch, merge and tag
> versions.
> In summary I've learned the following from all of those
> projects:
>
> 1. Try to keep a single line of development
> 2. Branch if you *MUST*
> 3. Tag if you *CAN*
>
> Tagging is helpfull to define 'milestones' during an
> ongoing
> development (e.g. assignment of symbolic names for all
> source files versions that form a well defined
> development
> step).
>
> Branching should either take place at the time when
> at least
> 2 major versions are out (e.g. delivered to customers) and
> need o be maintained or if different requirements for the
> product forces a split off of the development tree.
>
>
> For vtiger I do not see any need to split the
> development tree
> at the moment. However, the 5.0 is out and needs to be
> maintained
> while the next version is being developed.
>
> Therefor I'd strongly suggest to
>
> * Do bugfixing for the 5.0 version in the 5.0.1 branch
> * Keep the current development in the trunk line.
>
> Kind regards
> Jens
>
> On Tue, Sep 19, 2006 at 12:25:02PM -0400, Jeff
> Kowalczyk wrote:
> > Sergio A. Kessler wrote:
> > > I think this is wrong.
> > > I can understand (not agree) to create a 5.0.1 branch.
> but why you need
> > > to create a 5.1 branch at all ??? 5.1 development should be done
> in the
> > > trunk... branching 5.1 the only thing will do is
> complicate things...
> > > remember KISS (Keep It Simple, Stupid)
> >
> > I was going to complement Richie on the right
> branching naming, etc,
> > procedure...
> >
> > The timing of branching is equally important,
> however, and I think it's
> > too soon.
> >
> > We're going to have to decide (and document,
> and enforce) among the
> > 'stable trunk' vs other development models.
> >
> > We need to decide where new features get developed,
> and under what
> > conditions they get merged back to the 'trunk' or
> branch, as policy
> > decides.
> >
> > Everyone discussing this should read:
> >
> >
> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html
> >
> > with 'copies are cheap in subversion' in mind.
> Branches are easy, and the
> > numerous variety of branches (e.g for feature
> development) should be
> > short-lived (e.g. merge back to trunk or branch, then
> delete/move branch).
> >
> > Maintaining multiple long-lived branches is
> labor intensive, and might
> > only be undertaken to support long-term
> maintenance goals, on branches
> > that rarely want to merge changes from 'upstream'.
> >
> >
> > _______________________________________________
> > Get started with creating presentations online -
> http://zohoshow.com?vt
>
> --
>
> --------------------------------------------------------------------------------
> /
> +##+|##+ STRAWBERRY Jens Hamisch
> +v#+v v##+ EDV-Systeme GmbH Managing
> director
> / v v\v
> | . . . | Waldeckstr. 9a Car (Voice):
> (+49 172) 81 04 162
> | . | D-82515 Wolfratshausen Voice:
> (+49 8171) 41805-0
> | . | Fax:
> (+49 8171) 41805-59
> \ . / Tel.: (+49 8171) 41805-0 Email:
> jens at Strawberry.COM
> \____/ Strawberry at Strawberry.COM
>
> _______________________________________________
> Get started with creating presentations online -
> http://zohoshow.com?vt
>
> _______________________________________________
> Get started with creating presentations online - http://zohoshow.com?vt
>
>
_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20060920/0a534241/attachment-0004.html