Awesome, sounds great, guys; thanks for understanding. Depending on how badly I need 1.1.1-rc2 (I'll check my jobs tomorrow) I'll just build a local version for now. Should be easy, it's just been awhile. :-)
Thanks, Stephen On Sun Nov 23 2014 at 11:01:09 PM Patrick Wendell <pwend...@gmail.com> wrote: > 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 > > >
