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:26:13 GMT
I think that the issue is that the thing that is voted on is the tag.
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.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

_______________________________________________________________________
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. 

> -----Original Message-----
> From: Marc Prud'hommeaux [mailto:mprudhomapache@gmail.com] On 
> Behalf Of Marc Prud'hommeaux
> Sent: Sunday, November 12, 2006 12:53 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: [DISCUSS] Making a release
> 
> Craig-
> 
> The only difference is that we initially branch from the trunk and  
> perform the updates to the pom.xml files there, and then release  
> against the branch, correct?
> 
> I don't necessarily object to releasing off of a branch, but does it  
> really save any effort? After all, if release candidate problems  
> exist (as they have the last couple times I tried to create a  
> release), then so therefore commit changes to the branch, 
> we'll still  
> need to perform the additional step of merging the changes in the  
> branch back into the trunk, right?
> 
> 
> 
> On Nov 12, 2006, at 10:40 AM, Craig L Russell wrote:
> 
> > I'd like to propose something like this (edited the wiki page)
> >
> > The main difference is that upon starting the release process, we  
> > create a branch in which to resolve the release issues while  
> > maintaining the trunk for further development.
> >
> > h2. Tasks that need to be performed for each release
> >
> > {info}In the examples below, it is assumed that the current  
> > committed version of OpenJPA is *0.9.6-incubating-SNAPSHOT*, and  
> > the version of the official release will be *0.9.6-incubating*{info}
> >
> > # Make sure the [#One time setup] steps have been performed
> > # Create a branch from the trunk (or from a previous branch if  
> > maintaining a branch)
> > {code:none}
> > svn copy -m "Create branch for OpenJPA Release 0.9.6-incubating"
> >   https://svn.apache.org/repos/asf/incubator/openjpa/trunk
> >   
> https://svn.apache.org/repos/asf/incubator/openjpa/releases/0.9.6- 
> > incubating
> > {code}
> > # Change to the trunk for the next steps
> > # Update the pom.xml files to the subsequent version with the - 
> > SNAPSHOT suffix:
> > {code:none}
> > perl -pi -e "s;<version>0.9.6-incubating</version>;<version>0.9.7-

> > incubating-SNAPSHOT</version>;g" pom.xml */pom.xml
> > {code}
> > # Commit the POM changes in the trunk
> > {code:none}
> > svn commit -m "Updated to version 0.9.7-incubating-SNAPSHOT"
> > {code}
> > # Change to the branch for the new release for the following steps
> > # Update the POMs to remove "-SNAPSHOT" from the version. If you  
> > have perl installed, you can easily do it with a single command:
> > {code:none}
> > perl -pi -e 's;<version>0.9.6-incubating-SNAPSHOT</ 
> > version>;<version>0.9.6-incubating</version>;g' pom.xml */pom.xml
> > {code}
> > # Commit the POM changes
> > {code:none}
> > svn commit -m "Updated to version 0.9.6-incubating"
> > {code}
> > # Perform the build with documentation and install it in the local  
> > repository (this step is required because there is a bug in 
> Maven's  
> > javadoc generation aggregated between multiple modules):
> > {code:none}
> > mvn clean install -Pdocbook-profile,sign-release
> > {code}
> > {note}This operation will also sign the release artifacts with the  
> > *gpg* utility using the <username>@apache.org key. If your code  
> > signing key is under a different address, specify it by appending  
> > the following argument to the command above: - 
> > Dopenjpa.release.keyAlias=mysigningalias@somedomain.org{note}
> > # Verify the signatures:
> > {code:none}
> > gpg --multifile --verify openjpa-project/target/assembly/*.asc
> > {code}
> > # Build the javadocs and perform the deploy upload:
> > {code:none}
> > mvn verify deploy -Pjavadoc-profile,sign-release
> > {code}
> > # Start a vote for the release on the [mailto:open-jpa- 
> > dev@incubator.apache.org] mailing list. For an example of 
> the mail,  
> > see [this  archived vote|http://mail-archives.apache.org/mod_mbox/ 
> > incubator-open-jpa-dev/200611.mbox/%3c07C7A237-DE80-4BC5- 
> > B33D-2B8CDFEF21B7@apache.org%3e]
> > # If the vote is successful after 3 days, mail  
> > [mailto:general@incubator.apache.org] starting a vote for  
> > authorization to release
> > # Once that vote is successful, update the 
> [http://cwiki.apache.org/ 
> > openjpa/downloads.html] page with information about the download
> > # Tag the view with the release number:
> > {code:none}
> > svn copy -m "OpenJPA Release 0.9.6-incubating"
> >   
> https://svn.apache.org/repos/asf/incubator/openjpa/releases/0.9.6- 
> > incubating
> >   https://svn.apache.org/repos/asf/incubator/openjpa/tags/0.9.6- 
> > incubating
> > {code}
> > # The branch can now be used to apply patches for future releases  
> > using the branch as a basis (e.g. to create 0.9.6.1-incubating).
> >
> > Craig Russell
> > Architect, Sun Java Enterprise System 
> http://java.sun.com/products/jdo
> > 408 276-5638 mailto:Craig.Russell@sun.com
> > P.S. A good JDO? O, Gasp!
> >
> 
> 

Mime
View raw message