On 15/05/2009, sebb <[email protected]> wrote: > On 14/05/2009, Brian Fox <[email protected]> wrote: > > On Thu, May 14, 2009 at 3:19 PM, Sahoo <[email protected]> wrote: > > > > > Brian, > > > > > > Thanks for the excellent write up. In approach #2, when a build is done > by > > > just replacing RC versions by actual versions, since new binaries are > going > > > to be produced, don't they have to be tested again? > > > > > > > > Absolutely. However in the maven use case we don't need dozens of people > > testing every possible permutation like we try to do during the RCs. > > Assuming no code changed, we're really making sure that the binaries are > not > > completely broken. Regardless, this is the build that we do the voting on > so > > it does tend to have plenty of people using it before casting a vote. > > > > > > > > > I understand since no source code is changed(only version is changing in > > > pom.xmls), the chances of side effects are very low, but an organisation > > > with stricter quality control processes in place won't allow bits to be > > > released without them being tested. Once you involve testing, we are > back to > > > square one, where we are not sure if the bits are final. Or, am I > missing > > > anything? > > > > > > > > > Nope, you are correct and I agree with that policy. > > > > It's what we do at Sonatype as well as Maven. When a release is staged to > > Nexus, our QA thoroughly checks out that build. Those exact binaries are > > what eventually get promoted assuming they pass. > > > > I guess what I'm saying is that with the current maven release process, > you > > don't run RC's exactly the same way you do the final release. You need to > > rebuild it when you move from the RC to the release unfortunately, but you > > do still test the final binaries before promoting it.
Sorry, one more question: What happens if an error is found in the final binaries? It's unlikely, but AFAICT it is not impossible. > > This is exactly what > > the Nexus staging is about, it lets you test the binaries before you > promote > > it to your release repo, where it's too late to pull it back. > > > > > Thanks for answering my question so thoroughly. > > > > > > > > > > Thanks, > > > Sahoo > > > > > > > > > Brian Fox wrote: > > > > > >> First, I'll acknowledge that it's not easy/possible to "promote" an > > >> artifact > > >> from one version to another - say 1.0-RC-10 to 1.0. Lets just accept > that > > >> for now as it's a known issue that will be resolved down the road. Lets > > >> instead discuss a few ways to work within those bounds, since > discussing > > >> what "could be" doesn't help the issue now (which i believe this thread > > >> derived from the discussion on commons-dev regarding a pending > release). > > >> There are two approaches to this process, both are valid and I think > you > > >> could pick one based on your requirements: > > >> > > >> The first is to append a build number to your version that is always > > >> incremented. So instead of 1.0 you have 1.0-1 or 1.0-b1. You increment > > >> this > > >> forever until you have a release that is good and that's the one that > > >> stays, > > >> it could be 1.0-b10 or 1.0-500. I've used this approach before and it's > > >> similar to what many commercial orgs do (if you look under the hood at > MS > > >> versions for example, Vista SP1 is 6001.16659.070916-1443). In other > > >> words, > > >> the marketing for a release might be "1.0" but the actual version of > the > > >> files might be 1.0-xxxx. This may be ok for things where the end > result is > > >> a > > >> war or ear but probably not as desirable for projects like commons that > > >> release jars that are intended to be consumed. > > >> > > >> > > >> The approach we use in the Maven project is slightly different. We > used to > > >> stage versions like 2.0.8 over and over until we got it right. The > > >> problems > > >> with this approach where: 1) you need to rollback the tag and versions > > >> every > > >> time and 2) someone may have an artifact called 2.0.8 that was actually > > >> not > > >> the final 2.0.8. This was a bigger problem when we wanted to start > getting > > >> maven-users involved to test the release candidates. > > >> > > >> We instead use the RC versions (eg 2.0.9-RC10) until we get to a > release > > >> that we decide is ready to do. The versions are all staged on Nexus and > > >> the > > >> binaries are ditched each time we rebuild, but the tags stay in place. > > >> Since > > >> each release is uniquely versioned, we no longer have to revert the > > >> versions > > >> and we don't have to worry about someone having an RC and thinking > it's a > > >> final release. Since it's not possible currently to promote an actual > RC > > >> to > > >> the final release (eg 2.0.9-RC10 to 2.0.9), we simply rebuild and > restage > > >> one final time using the new release number (eg 2.0.9). The original > RCs > > >> were never called for formal votes as we know it's unlikely to pass, > think > > >> of them as tagged snapshots. Only the final release is voted upon and > in > > >> this fashion, by the time we reach the final release it's highly > unlikely > > >> we > > >> will find any showstoppers, since the release process was followed for > > >> each > > >> RC (a practice run 10+ times if you will). > > >> > > >> Yes there are issues where someone _could_ make a change in between the > > >> last > > >> RC and the final release, but when we are in this cycle it is expected > > >> that > > >> only the RM is making changes to that branch (once the RC process > starts, > > >> it's moved to a separate branch) and it's watched very closely. In > reality > > >> it's not an issue. > > >> > > >> Hope that helps. > > >> Brian > > >> <snip/> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
