Re: Test 1.0.3 Artifacts (Round 2)
On 8/23/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 8/20/06, Sean Schofield [EMAIL PROTECTED] wrote: I agree with both sides of this argument and to me, there is no ideal solution. I think at this stage (serious but not final evaluation) we just keep -SNAPSHOT and ask users to download and review. Before voting we can tweak the version number and label SVN. We can ask committers to build from SVN tag and test and vote on that. At this point its unlikely there are any issues but if there are, the committers should be smart enough to know how to clear out their maven repo (and we can remind them with specific instructions.) We definitely don't want to skip version numbers. So my proposal is to involve everyone in the beta testing but do not distribute the final version to vote on so we can prevent mass confusion. If non committers want to participate they can build from the *tagged* svn version (not the trunk) and they do so at their own risk. snip/ Makes sense, going a step ahead, if a committer could generously post (rather than deploy) the bits in their personal webspace (rather than a maven snapshot repository, which presumably is where folks can unknowingly obtain the premature artifacts from) -- that would lower the barrier for participation, which is a good thing IMO. Now that we're building with Maven2, there are two kinds of things being deployed: * Release artifacts (bundled-up versions of the sources and compiled code, essentially like what the nightly builds produce) * Maven artifacts (jars and poms that need to be published into a Maven repository to be accessible). For the former, I did indeed do what Rahul suggests ( http://people.apache.org/~craigmcc/shale-proposed-release-1.0.3 but this is going away now that it's been completed), and that was part of the please test message to the dev list. For the latter, it wouldn't really make sense to set up yet another Maven2 repository in the release manager's personal web space ... the http://people.apache.org/repo/m2-snapshot-repository exists for this purpose. Indeed, the nightly build process has been posting 1.0.3-SNAPSHOTbuilds of these poms and jars all along (and, this is where the initial 1.0.3 test builds were posted). So, if you've been using 1.0.3-SNAPSHOT and wanted to try out 1.0.3, you'd need only switch the version number in your dependencies and you'd get the right stuff automatically ... no need to configure yet another repository entry for the temporarily posted bits. Craig -Rahul Sean snap/
Re: Test 1.0.3 Artifacts (Round 2)
On 8/23/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/23/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 8/20/06, Sean Schofield [EMAIL PROTECTED] wrote: snip/ So my proposal is to involve everyone in the beta testing but do not distribute the final version to vote on so we can prevent mass confusion. If non committers want to participate they can build from the *tagged* svn version (not the trunk) and they do so at their own risk. snip/ Makes sense, going a step ahead, if a committer could generously post (rather than deploy) the bits in their personal webspace (rather than a maven snapshot repository, which presumably is where folks can unknowingly obtain the premature artifacts from) -- that would lower the barrier for participation, which is a good thing IMO. Now that we're building with Maven2, there are two kinds of things being deployed: * Release artifacts (bundled-up versions of the sources and compiled code, essentially like what the nightly builds produce) * Maven artifacts (jars and poms that need to be published into a Maven repository to be accessible). For the former, I did indeed do what Rahul suggests ( http://people.apache.org/~craigmcc/shale-proposed-release-1.0.3 but this is going away now that it's been completed), and that was part of the please test message to the dev list. snap/ Yup. For the latter, it wouldn't really make sense to set up yet another Maven2 repository in the release manager's personal web space ... the http://people.apache.org/repo/m2-snapshot-repository exists for this purpose. Indeed, the nightly build process has been posting 1.0.3-SNAPSHOTbuilds of these poms and jars all along (and, this is where the initial 1.0.3 test builds were posted). So, if you've been using 1.0.3-SNAPSHOT and wanted to try out 1.0.3, you'd need only switch the version number in your dependencies and you'd get the right stuff automatically ... no need to configure yet another repository entry for the temporarily posted bits. snip/ I tried to be careful in phrasing that, but didn't have much success ;-) Ofcourse, setting a m2 repository in personal webspace will be no fun (and a waste of time), but just posting the artifacts there (not in any particular repository layout) might be possible. For simplicity, lets say we have a simple project which produces just one artifact, foo.jar (yes, I oversimplified!). I can do a mvn compile and scp foo.jar (with sums and sigs) to ~rahul. If folks think its OK (they will have to deploy manually to local repo), we deploy to the remote repo(s) of choice. I claim that the extra effort required to manually deploy the artifacts in the local repo (by folks who are testing it) actually works in our favor, since there is little chance to accidently acquire the artifact (as against the apache snapshot repos, which are fairly well-known) and thereby, forget to replace it with the final v1.0.3. -Rahul Craig -Rahul Sean
Re: Test 1.0.3 Artifacts (Round 2)
On 8/20/06, Sean Schofield [EMAIL PROTECTED] wrote: I agree with both sides of this argument and to me, there is no ideal solution. I think at this stage (serious but not final evaluation) we just keep -SNAPSHOT and ask users to download and review. Before voting we can tweak the version number and label SVN. We can ask committers to build from SVN tag and test and vote on that. We can tweak the procedure next time ... but for this time I'm going to try to role the final set of bits to propose for the vote this evening. Can we please hold up on commits until after I finish that, tag it, and update the POMs for 1.0.4-SNAPSHOT? Craig At this point its unlikely there are any issues but if there are, the committers should be smart enough to know how to clear out their maven repo (and we can remind them with specific instructions.) We definitely don't want to skip version numbers. So my proposal is to involve everyone in the beta testing but do not distribute the final version to vote on so we can prevent mass confusion. If non committers want to participate they can build from the *tagged* svn version (not the trunk) and they do so at their own risk. Sean On 8/19/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/19/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/19/06, Craig McClanahan [EMAIL PROTECTED] wrote: Wendy wrote: A non-SNAPSHOT version should be built exactly once if at all possible. Once it's in a repository, for all intents and purposes it *is* released and should not be changed. Next time around let's just evaluate the -SNAPSHOT version until it's ready to tag and release. Isn't that why we have a test repository for snapshots? Otherwise, you'd only get one shot at publishing any particular version number, and we'd end up with lots of holes in the sequence of version numbers ever actually published. You can't have it both ways. :) Either we do test builds and discard them if necessary, or we build release candidates as 1.1.3-RC1, -RC2, etc. Or, we train people who are evaluating test builds about what to do. But we should not be building and re-building (and deploying to a public repository) anything that does not have a SNAPSHOT version number. We would never go back and 're-do' a release candidate, correct? Agreed ... but evaluating release candidate bits (even if the sigs are posted) is *not* the same as evaluating the here's the real bits. It puts too much trust in the release manager not to screw up the final process, if the vote is on a release candidate. On the other hand, if we're just interested in evaluating interim builds that *might* end up being a release, we can just keep updating the snapshots and say please try again ... iterate until satisfied ... without any special candidate markings at all. Taking the next bits out of order... I would prefer to see our release votes be about these are the exact bits that I want to push to the dist directory, and to ibiblio. Agreed. The problem with evaluating the snapshots is we're trusting that nothing goes wrong with the real build process after version numbers are updated in the POMs. ... We definitely don't want to be pushing test artifacts with non-SNAPSHOT versions as a normal course of action, but in the roll-up to a release it seems like the only way to do it. We review and fix the snapshots until we're happy with them. (For MyFaces, I insert the last-changed svn revision number in the distribution filename.) Then we change the version number, build and deploy it once as 1.1.3, and vote on that. If there's a problem, move on to the next version. Can you explain why you think missing version numbers will be a problem? Several issues: * Perception. Skipping x.y.z release numbers is not a common practice across open source projects, and will create questions in some peoples's minds about what happened ... and maybe lead to doubts if the developers are really smart enough to be depended on. * Confusion. Think of all the bug reports that have been marked as will be included in 1.0.3. We're *assuming* that people will understand that, if we skip 1.0.3 because of packaging issues in the test build, that 1.0.4 will include all of those changes. * More perception. We've stated publicly we're working on a 1.0.3release. Skipping it, and doing a 1.0.4 instead, increases the perception that we never release what we say we're going to. It could be perceived as giving us an excuse to *never* release because we can't get the build right. * Mechanics. Admittedly nowhere near the amount of trouble that the previous issues are, but it's a bunch of extra work (editing poms, setting up JIRA version numbers, etc.), taking time that could be better spent getting the release out in the first place. Craig I'll look at it tomorrow
Re: Test 1.0.3 Artifacts (Round 2)
We can tweak the procedure next time ... but for this time I'm going to try to role the final set of bits to propose for the vote this evening. Can we please hold up on commits until after I finish that, tag it, and update the POMs for 1.0.4-SNAPSHOT? That will work. Craig Sean
Re: Test 1.0.3 Artifacts (Round 2)
On 8/18/06, Craig McClanahan [EMAIL PROTECTED] wrote: WARNING: If you have previously installed 1.0.3 artifacts from the earlier test build evaluation into your local repository, you will need to manually replace them, because these are not SNAPSHOT version numbers. A non-SNAPSHOT version should be built exactly once if at all possible. Once it's in a repository, for all intents and purposes it *is* released and should not be changed. [1] Next time around let's just evaluate the -SNAPSHOT version until it's ready to tag and release. (2) Releaseable .tar.gz and .zip artifacts Do we need both? I think .zip is sufficient. KNOWN ISSUE: The version number (1.0.3) is not included in the top level directory of the war distributions. Need to figure out how to not do this, without disabling the generation of webapps that don't require version numbers in the context path. I'll look at it tomorrow afternoon, but I suspect renaming the files will be the easiest solution for 1.0.3. KNOWN ISSUE: The -dist suffix on all of the above distibutions is somewhat useless. We can rename the files, but it would be better to identify a way to make the assembly instructions do what we want in the first place. The latest version of the assembly plugin has an option for this. It would require changing the assembly descriptors to the new format, and I haven't been able to get it to do what I want. Another issue: The portlet-api jar is included in WEB-INF/lib of shale-blank. I didn't check the others. Also, LICENSE and NOTICE are in WEB-INF/classes. META-INF is probably more appropriate, as with the jars. [1] (Yes, I know I just rebuilt Struts 1.3.5, but at least nothing had changed in svn since the original.) -- Wendy
Re: Test 1.0.3 Artifacts (Round 2)
On 8/18/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/18/06, Craig McClanahan [EMAIL PROTECTED] wrote: WARNING: If you have previously installed 1.0.3 artifacts from the earlier test build evaluation into your local repository, you will need to manually replace them, because these are not SNAPSHOT version numbers. A non-SNAPSHOT version should be built exactly once if at all possible. Once it's in a repository, for all intents and purposes it *is* released and should not be changed. [1] Next time around let's just evaluate the -SNAPSHOT version until it's ready to tag and release. Isn't that why we have a test repository for snapshots? Otherwise, you'd only get one shot at publishing any particular version number, and we'd end up with lots of holes in the sequence of version numbers ever actually published. The problem with evaluating the snapshots is we're trusting that nothing goes wrong with the real build process after version numbers are updated in the POMs. I would prefer to see our release votes be about these are the exact bits that I want to push to the dist directory, and to ibiblio. We definitely don't want to be pushing test artifacts with non-SNAPSHOT versions as a normal course of action, but in the roll-up to a release it seems like the only way to do it. (2) Releaseable .tar.gz and .zip artifacts Do we need both? I think .zip is sufficient. Works for me. I like tar.gz better when I've got executables included, or when I want to maintain file permissions ... but neither of those tend to be an issue for our distros. KNOWN ISSUE: The version number (1.0.3) is not included in the top level directory of the war distributions. Need to figure out how to not do this, without disabling the generation of webapps that don't require version numbers in the context path. I'll look at it tomorrow afternoon, but I suspect renaming the files will be the easiest solution for 1.0.3. I can live with that for this version. KNOWN ISSUE: The -dist suffix on all of the above distibutions is somewhat useless. We can rename the files, but it would be better to identify a way to make the assembly instructions do what we want in the first place. The latest version of the assembly plugin has an option for this. It would require changing the assembly descriptors to the new format, and I haven't been able to get it to do what I want. We can live with it for this time. Another issue: The portlet-api jar is included in WEB-INF/lib of shale-blank. I didn't check the others. It's in all of them. I'll need to mark it as provided, like we did for servlet and jsp api stuff. Also, LICENSE and NOTICE are in WEB-INF/classes. META-INF is probably more appropriate, as with the jars. Yep ... I'll make a pass through the same sort of changes as for the libraries. [1] (Yes, I know I just rebuilt Struts 1.3.5, but at least nothing had changed in svn since the original.) :-) -- Wendy Craig
