Re: Voting on releasing RC artificats as Final
On Mon, 21 May 2007, Henri Yandell wrote: Don't your jars contain the version number too? Yeah, everything seems to :/ The most recent release types I've done are the type where you create the exact release and put it in your ~login where it's voted on. I like this because it makes the actual release extremely easy. The biggest downsides are a) someone might be idiotic and use a random jar from a ~login and b) if you have the release date in there somewhere you have to use the day the vote ends. That makes sense as a plan. While the rc has -final- in the artificat names, you can put it in a directory called -rc, and add a readme. Since you're probably just going to include the url to the files in the vote email to -dev (who ought to know what it means), it strikes me it ought to be fine. I've updated the poi release guide to follow your method, so we'll have to see how it works for 3.0.1! Thanks Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Voting on releasing RC artificats as Final
Hi All For the 3.0 release of POI, we followed the advice on voting on artificats, the not the state of the tree. So, we used our ant script to produce RC artificats, signed them, and placed them on people.apache.org for review. After the vote, we renamed the files from -RC4- to -FINAL-, tweaked the filenames inside the .md5 files, and copied into /dist/. Two snags though: * we had to re-generate the maven pom, and re-sign it, as that holds the release version in it, which changed * we forgot that the .tar.gz and .zip files all have poi-3.0-rc4 as their base directory name, since the directory name is generated dynamically in build.xml What do other people do about this for their releases, when voting on artificats? Do you do each build as if it was -FINAL (so that gets embeded into all the directory names etc), then rename the artificats for voting, or something else? Thanks Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Voting on releasing RC artificats as Final
For commons transaction I did exactly that. Create/sign the RC as if it was the final release, but only put it on temporary storage without notifying anyone external. IMHO a RC is not meant to check for remaining bugs, but rather to see if the distro looks ok, installs, etc. That means the RC is never actually released to the users. This is what betas or milestones are for. Disclaimer: Certainly not official. This is my personal way of making releases. Cheers Oliver 2007/5/21, Nick Burch [EMAIL PROTECTED]: Hi All For the 3.0 release of POI, we followed the advice on voting on artificats, the not the state of the tree. So, we used our ant script to produce RC artificats, signed them, and placed them on people.apache.org for review. After the vote, we renamed the files from -RC4- to -FINAL-, tweaked the filenames inside the .md5 files, and copied into /dist/. Two snags though: * we had to re-generate the maven pom, and re-sign it, as that holds the release version in it, which changed * we forgot that the .tar.gz and .zip files all have poi-3.0-rc4 as their base directory name, since the directory name is generated dynamically in build.xml What do other people do about this for their releases, when voting on artificats? Do you do each build as if it was -FINAL (so that gets embeded into all the directory names etc), then rename the artificats for voting, or something else? Thanks Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Voting on releasing RC artificats as Final
Nick Burch wrote: What do other people do about this for their releases, when voting on artificats? Do you do each build as if it was -FINAL (so that gets embeded into all the directory names etc), then rename the artificats for voting, or something else? For Tomcat, every release candidate gets a new version number. We upload the RC to tomcat.a.o/dev/dist and test it for a few days. If we find a show stopper, we delete the uploaded RC and start again (it is still tagged in svn if we ever need to go back). If no major issues are found, we vote on it (Alpha/Beta/Stable) and after the vote the files are copied to www.a.o/dist and an announcement sent out. HTH, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Voting on releasing RC artificats as Final
On 5/21/07, Nick Burch [EMAIL PROTECTED] wrote: Hi All For the 3.0 release of POI, we followed the advice on voting on artificats, the not the state of the tree. So, we used our ant script to produce RC artificats, signed them, and placed them on people.apache.org for review. After the vote, we renamed the files from -RC4- to -FINAL-, tweaked the filenames inside the .md5 files, and copied into /dist/. Two snags though: * we had to re-generate the maven pom, and re-sign it, as that holds the release version in it, which changed * we forgot that the .tar.gz and .zip files all have poi-3.0-rc4 as their base directory name, since the directory name is generated dynamically in build.xml What do other people do about this for their releases, when voting on artificats? Do you do each build as if it was -FINAL (so that gets embeded into all the directory names etc), then rename the artificats for voting, or something else? Don't your jars contain the version number too? The most recent release types I've done are the type where you create the exact release and put it in your ~login where it's voted on. I like this because it makes the actual release extremely easy. The biggest downsides are a) someone might be idiotic and use a random jar from a ~login and b) if you have the release date in there somewhere you have to use the day the vote ends. I don't like the Tomcat/Struts/HTTP Server style of bumping the version each time, but only really because they abuse their numbering schemes. ie) 1.3.5, 1.3.8 etc rather than 1.3.5build1, 1.3.5build4. The general principle is sound and if your community can do the testing to be able to decide on a GA, then it's good. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
