openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@bea.com>
Subject RE: [DISCUSS] Making a release
Date Sun, 12 Nov 2006 21:46:04 GMT
> On Nov 12, 2006, at 1:26 PM, Patrick Linskey wrote:
> 
> > I think that the issue is that the thing that is voted on 
> is the tag.
> 
> Is that actually right? My understanding was that the thing that is  
> voted on is the artifacts (in this case, the binary and source zip  
> archives), and that the VCS is not a fundamental part of the release  
> voting process.

I guess I meant "the thing that is voted on is what was built from the
tag." Assuming that development continues, then if you work from the
tag, people only need to consider the differences that have happened on
the tag. If we build from the mainline, then people need to consider all
changes.

> > Additional work might be happening as the vote proceeds; that  
> > additional
> > work may or may not be ready for prime-time.
> >
> > I expect that over time, we'll be branching earlier anyways 
> and doing
> > destabilizing work on a branch separate from the release candidate
> > branch.
> 
> True, but my question is whether we should make branches for 
> the sole  
> purpose of cutting a release or not, which is why I was wondering if  
> actually saves effort or not.

My understanding is that tags and branches are the same thing in svn, so
Craig's proposal was that the work of fixing things would happen in the
dir created for the tag, and then get merged (or duplicated) into
mainline.

Consider, for example, my localizer optimization, Abe's nested subquery
fixes, and my JDK1.4 switchover. Those all happened after the tag was
created. If we include those changes in the thing that we vote on next,
then presumably I should take those changes into account (including
testing to make sure that the new JDK1.4 stuff really works, etc.) when
voting. I'd prefer to just automatically saying "+1" since I gave a +1
last time and the changes you made to resolve Eddie's issues are things
that I agree with.

For the particular issues at hand, I don't think that there is much
destabilization, but I do agree that jumping back to current main and
re-tagging seems like it's bound to cause problems at some point. It
seems like once there's a 0.9.6 tag, we shouldn't be changing the number
of the mainline back to 0.9.6, but should instead change things in the
tag.

Speaking of which, is there a way in svn to freeze a directory, so that
once 0.9.6 is approved, we can't mutate that tag / branch / directory?

-Patrick
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

Mime
View raw message