Phil Steitz wrote on Wednesday, February 07, 2007 9:05 PM: [snip]
> Could be this is the direction that we need to go for the > heavily reused > components. I cut an RC1 for [dbcp] a couple of weeks ago > and published > the RC1 snap to the snapshot repo so people could download > and test. I was > afraid to do what I would have liked to - make it a "public" > RC as we used > to do, announcing it on tomcat-user, Jakarta general, etc, > but I really > think that is the right way to go. Testing RCs is an important part of > getting to GA, IMHO and if it offends the gods to put RCs out > for general > consumption, then I think we need to move to the initial release, GA > labelling. I don't like the idea of having people download and test > *different* jars with the same names / artifact ids and I don't like > releasing components that have not been tested. > > The problem with the release-then-fix approach is it leads to lots of > dot-different release jars out in production use, some of > them potentially > bugged, and I don't see that as good in a mavenized world or > for heavily > reused libraries in general. It works OK for "top predators" > like Struts, > Tomcat, HTTPd, but could get dicey lower down in the food > chain, IMHO. I > could be cracked here - pls let me know if I am the only one > thinking this > way. > > I'm strongly in favour of 2). It's safer and it makes the release >> easier. The only negatives are: >> >> 1) There's a chance that someone might take a jar from the rc1/ >> directory in ~bayard and charge off to use it. So be it - that's >> there risk. >> >> 2) I don't like leaving svn in a state of having a release version, >> so I roll the version back from 1.4 to 1.4-SNAPSHOT after doing the >> release. An alternative might be to branch 1.4 off for the release >> and have a 1.4-release branch for preparing the release on, but that >> a) still makes me uncomfortable to have a release version in and b) >> will be messy having one of those for every release. > > > If we have to do things this way, I would use a release > branch, but I still > don't yet see the compelling need to reverse history - i.e., > what problem > exactly are we needing to solve here? What exactly is illegal about > publishing release candidates and having people test them? We publish > nightlies now and the "RC" designation, which is clear and in > all of the > names, tells users that the artifacts are not yet official > releases. I am > not trying to be difficult here, just want to understand what > the issue is. +1 It should not be a problem to make a final release after a RC has passed the vote. If you don't trust your build tool to (re)create the same artifact now with the final revision number, it seems it is more a question of trusting that build tool ... :D - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
