[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
CVS Branching [was RE: [higgins-dev] Code Changes]
|
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
