Hi Andy, On May 6, 2009, at 4:05 AM, Andy Jefferson wrote:
Having tried this "release process" I find the following. In step 7 it says"7. Sign the artifacts. You must have a gpg key in order to perform this step.The sign-directory script is checked into jdo/bin.
The script is in the bin directory parallel to trunk and releases. You may have to do an svn checkout if you don't have the entire jdo project.
Edit this script to refer to your own environment (do not check it in). bin/sign-directory releases/2.n/dist/jdo2.<n>-rc<m>" yet there is no directory with a name like that. "releases/2.3-ea/dist" is the closest I have. Under that we have db m1-ibiblio-rsync-repository Is this correct ?These are presumably created by the steps before that. So all files underthere need signing. Ok.
Right. All the .jar, .tgz, etc. artifacts need a detached signature and checksum.
If I look in the poms under "releases/2.3-ea/dist/m1-ibiblio-rsync-repository/" they all have <currentVersion>${jdo.currentVersion}</currentVersion>This also seems to be what is being pushed about in IBiblio. It just basically seems wrong to me. They should have real versions in when over there. Isuggest an extra step, before the signing*** Update all poms under m1-ibiblio-rsync-repository to be the real version***
This was supposed to be fixed by the parent pom. Something musta gone bad...
Another question : there is no mention of checking in the stuffunder "releases". Some seem to have been checked in and some not. What is thepolicy ?
We need to have a permanent svn archive of what we released.
Also, how does the Maven2 repository "maven-metadata.xml" file get changed ? Is it manually hacked somewhere ? and if so, how does it then get pushed ontoIBiblio ?
It needs to be manually hacked for now, and made part of the release process.
Craig
Thx -- Andy (DataNucleus - http://www.datanucleus.org)
Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[email protected] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
