Hey Stephen, Thanks for bringing this up. Technically when we call a release vote it needs to be on the exact commit that will be the final release. However, one thing I've thought of doing for a while would be to publish the maven artifacts using a version tag with $VERSION-rcX even if the underlying commit has $VERSION in the pom files. Some recent changes I've made to the way we do publishing in branch 1.2 should make this pretty easy - it wasn't very easy before because we used maven's publishing plugin which makes modifying the published version tricky. Our current approach is, indeed, problematic because maven artifacts are supposed to be immutable once they have a specific version identifier.
I created SPARK-4568 to track this: https://issues.apache.org/jira/browse/SPARK-4568 - Patrick On Sun, Nov 23, 2014 at 8:11 PM, Matei Zaharia <matei.zaha...@gmail.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
