Interesting, perhaps we could publish each one with two IDs, of which the rc one is unofficial. The problem is indeed that you have to vote on a hash for a potentially final artifact.
Matei > On Nov 23, 2014, at 7:54 PM, Stephen Haberman <stephen.haber...@gmail.com> > wrote: > > Hi, > > I wanted to try 1.1.1-rc2 because we're running into SPARK-3633, but > the"rc" releases not being tagged with "-rcX" means the pre-built artifacts > are basically useless to me. > > (Pedantically, to test a release, I have to upload it into our internal > repo, to compile jobs, start clusters, etc. Invariably when an rcX artifact > ends up not being final, then I'm screwed, because I would have to clear > the local cache of any of our machines, dev/Jenkins/etc., that ever > downloaded the "formerly known as 1.1.1 but not really" rc artifacts.) > > What's frustrating is that I know other Apache projects do rc releases, and > even get them into Maven central, e.g.: > > http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.tapestry%22%20AND%20a%3A%22tapestry-ioc%22 > > So, I apologize for the distraction from getting real work done, but > perhaps you guys could find a creative way to work around the > well-intentioned mandate on artifact voting? > > (E.g. perhaps have multiple votes, one for each successive rc (with -rcX > suffix), then, once blessed, another one on the actually-final/no-rcX > artifact (built from the last rc's tag); or publish no-rcX artifacts for > official voting, as today, but then, at the same time, add -rcX artifacts > to Maven central for non-binding/3rd party testing, etc.) > > Thanks, > Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
