[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: CVS Branching [was RE: [higgins-dev] Code Changes]
|
Can someone please send instructions to the list describing how to manage
this in Eclipse?
Thanks,
Mike
higgins-dev-bounces@xxxxxxxxxxx wrote on 06/08/2007 01:39:41 PM:
> So, we discussed this with Paul via telephone and he agreed that we
> need a good long term approach and that we should proceed with what
> we proposed here below. We can refine it as we go.
>
> For naming, I suggest we name our branches according to the
> milestone they represent. The branch names cannot contain spaces
> nor the characters '$,.:;@|' and they must begin with an alpha
> character. So, I suggest this:
>
> M<Major Version>-<Minor Version>-<Sub-Release, if any>
>
> For milestone 0.8, it'd be:
>
> M0-8
>
> Jim is looking at options for cross-project usage of the same branch
> so we could easily move back and forth in eclipse for dependant
> projects.
>
> I'm going to proceed according to this plan for my projects.
>
> Tom
>
> >>> "Tom Doman" <TDoman@xxxxxxxxxx> 6/8/2007 10:22 AM >>>
> We've been discussing this here at Novell (Andy, Jim, and I) and here's
> our suggestion. We should create M0.8 branches and have Catalyst,
> etc. bug fixes checked into that branch. HEAD should be for current
> development until such time as we want to stabilize for the next
> milestone, M0.9. Then, we'll branch for that. That way, those checking
> out and\or building projects will know exactly what base they are
> dealing. So, if a stable build is wanted, HEAD is never the place to
> get it. And as bug fixes are made to branches, those can be merged
> back into HEAD.
>
> In the nightly builds, we can build any of the branches we're currently
> supporting for ongoing development but we always have stable branches
> of each milestone that we've produced.
>
> How does that sound?
>
> Tom
>
> >>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 6/8/2007 8:51 AM >>>
> My suggestions:
> - the HEAD is where bug-fixing and other very low risk changes should be
> committed.
> - if any of us do create a branch and commit code to it, they'll be
> responsible for remerging those changes to the HEAD stream after
Catalyst
> (June 27)
>
> Tom wrote:
> >
> > Shall we come up with a Higgins prescribed way to name Branches and
> > Versions if we're going to do this? I'm ready to branch the JNDI CP
> > for some changes but I'm not sure how to name nor what our "go
> > forward" strategy is as far as merging goes. Will we always merge
> > into HEAD eventually? Or will we pick a branch named by our current
> > milestone? Something else? We need something that makes sense
> > and will make it easy for developers to participate.
> >
> > I freely admit to being a CVS newbie in this regard. I've never
> > branched, versioned, or, of course, merged. So, I'm looking for
> > some seasoned guidance and sensical plan here. Anyone?
> >
> > Thanks,
> > Tom
> >
> > >>> Anthony Nadalin <drsecure@xxxxxxxxxx> 6/6/2007 2:12 PM >>>
> >
> > So this is where I get worried as since .8 has some changes in HBX and
> > RPPS
> > that are not done this may break the demo, so I would like to make
sure we
> > freeze HBX and RPPS like real soon to avoid issues in this space. So
any
> > changes in HBX or RPPS we will fork and resolve after interop
> >
> > Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> >
> >
> >
> > "Paul Trevithick"
> > <paul@socialphysi
> > cs.org> To
> > Sent by: "'Higgins \(Trust Framework\)
> > higgins-dev-bounc Project developer discussions'"
> > es@xxxxxxxxxxx <higgins-dev@xxxxxxxxxxx>
> > cc
> >
> > 06/06/2007 12:37 Subject
> > PM RE: [higgins-dev] Code Changes
> >
> >
> > Please respond to
> > "Higgins \(Trust
> > Framework\)
> > Project developer
> > discussions"
> > <higgins-dev@ecli
> > pse.org>
> >
> >
> >
> >
> >
> >
> > M0.8 is not done. At this point I propose we hold off on declaring
victory
> > on M0.8 until after the interop.
> >
> >
> > From: higgins-dev-bounces@xxxxxxxxxxx
> > [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Nadalin
> > Sent: Wednesday, June 06, 2007 12:50 PM
> > To: Higgins (Trust Framework) Project developer discussions
> > Cc: 'Higgins (Trust Framework) Project developer discussions';
> > higgins-dev-bounces@xxxxxxxxxxx
> > Subject: Re: [higgins-dev] Code Changes
> >
> >
> >
> > yep that would be good, I also assume we are complete on milestone .8
and
> > we can hold on that until after the interop
> >
> > Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> > Inactive hide details for "Jim Sermersheim" <jimse@xxxxxxxxxx>"Jim
> > Sermersheim" <jimse@xxxxxxxxxx>
> >
> >
> >
> >
> > "Jim
> > Sermershe
> > im"
> > <jimse@no
> > vell.com> To
> >
> > Sent by: "'Higgins (Trust
Framework)
> > higgins-d Project developer
> > ev-bounce discussions'"
> > s@eclipse <higgins-dev@xxxxxxxxxxx>
> > .org
> > cc
> >
> > 06/06/200
> > 7 11:44 Subject
> > AM
> > Re: [higgins-dev] Code
> > Changes
> >
> >
> >
> > Please
> > respond
> > to
> > "Higgins
> > \(Trust
> > Framewor
> > k\)
> > Project
> > develope
> > r
> > discussi
> > ons"
> > <higgins
> > -dev@ecl
> > ipse.org
> > >
> >
> >
> >
> >
> >
> >
> >
> > sounds good.
> >
> > If/when we need to do a bug fix, I suppose we should notify the list
just
> > in case of unforseen ramifications?
> >
> > >>> Anthony Nadalin <drsecure@xxxxxxxxxx> 6/6/07 10:33 AM >>>
> >
> >
> > I would like to propose that all non-bug related changes be held or
forked
> > until after June 25, thus putting a freeze on current code before the
> > Burton Interop, as we don't want to spend resources chasing bugs that
> > changes might cause, and we would resume normal processes after June
25th
> >
> > Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
> > _______________________________________________
> > higgins-dev mailing list
> > higgins-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/higgins-dev
> > _______________________________________________
> > higgins-dev mailing list
> > higgins-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/higgins-dev
> >
> >
> > _______________________________________________
> > higgins-dev mailing list
> > higgins-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/higgins-dev
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
