I would add that there are additional requirements on a binary convenience release.
I think that Taylor is going down the right path. I haven't had time to look at the trial artifacts in detail and won't for the next week at least, but it would a grand idea if somebody could do so. Spending the time practicing the art of release like this before it is supposed to be a real release is really a smart thing to do. On Fri, Jan 3, 2014 at 2:42 AM, Gianmarco De Francisci Morales < [email protected]> wrote: > Apache Software never releases the binary files. > The binary release is a commodity for people but the only Apache approved > release is source code. > > > http://www.apache.org/dev/release.html > > The Apache Software Foundation produces open source software. All releases > are in the form of the source materials needed to make changes to the > software being released. In some cases, binary/bytecode packages are also > produced as a convenience to users that might not have the appropriate > tools to build a compiled version of the source. In all such cases, the > binary/bytecode package must have the same version number as the source > release and may only add binary/bytecode files that are the result of > compiling that version of the source code release. > > Cheers, > > -- > Gianmarco > > > On 2 January 2014 17:01, P. Taylor Goetz <[email protected]> wrote: > > > I put together a pull request for conversion to maven [1]. It’s set up to > > handle a lot of the things needed for the release process (RAT report, > > dependency report, signing, etc.), and also be easy for developers (a > > top-level `mvn install` will build the project and run unit tests). > There’s > > additional documentation in the pull request comment. I’d appreciate > > feedback from developers/committers. > > > > You can find a sample “maven site” report here [2], and sample source and > > binary releases here [3]. > > > > If a mentor could take a look at the sample releases and let me know how > > close they are to passing muster, I would appreciate it. My > (inexperienced) > > gut feeling is that the source release is close, but we probably need > more > > work on the NOTICE file for the binary release (the build is set up with > > separate LICENSE/NOTICE files for source and binary releases). > > > > [1] https://github.com/apache/incubator-storm/pull/14 > > [2] http://people.apache.org/~ptgoetz/storm/report/ > > [3] > > > http://people.apache.org/~ptgoetz/storm/release/0.9.1-incubating-SNAPSHOT/ > > > > Thanks, > > > > Taylor > > > > On Dec 23, 2013, at 10:04 AM, Matt Franklin <[email protected]> > > wrote: > > > > > On Sat, Dec 21, 2013 at 12:14 AM, James Xu <[email protected]> > > wrote: > > > > > >> Leiningen is the best build tool for Clojure projects, while Maven is > > the > > >> first class citizen in ASF Infrastructure. Can we keep them both? Just > > like > > >> Nathan’s storm-starter: https://github.com/nathanmarz/storm-starter , > > the > > >> project itself is managed by Leiningen, but storm user who knows only > > maven > > >> can use the > > >> > https://github.com/nathanmarz/storm-starter/blob/master/m2-pom.xmlthere > > >> to build. > > >> > > > > > > The concerns Ted has mostly stem from the activities that need to > happen > > > during the release process. It is technically possible to build with > > > Leiningen and only do release builds with Maven, but I would recommend > > > against having two build strategies for the project. > > > > > > > > >> > > >> On 2013年12月21日, at 上午5:26, Ted Dunning <[email protected]> wrote: > > >> > > >>> The difference between Maven and Leiningen in the Apache context > hasn't > > >>> even really come into view. When it comes to IP clearance, packaging > > in > > >>> standard ways, signing and interfacing with Nexus, Maven is going to > be > > >>> worlds easier. It isn't so much about doing the things that most > > >>> developers know and care about better, it is about doing the things > > that > > >>> most developers don't care about, but which are *really* important to > > get > > >>> right. Because few developers care, very few developers will get > these > > >>> things right. Maven helps with this in two ways. First, many Apache > > >>> projects use maven so there is a tribal knowledge available to help > > out. > > >>> Second, Maven incorporates community development into normal > practice. > > >>> This means that if one project makes project signing better, > everybody > > >>> wins. This community focus means that enough resources actually get > > >> spent > > >>> on the frictional parts of releasing code to make them much less > > painful. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> On Fri, Dec 20, 2013 at 12:29 PM, Brian O'Neill < > [email protected] > > >>> wrote: > > >>> > > >>>> +1 for a switch to maven > > >>>> > > >>>> I¹m all for lowering the hurdles for other developers to get > involved. > > >>>> > > >>>> By eliminating the zeromq dependency and converting to maven, we¹ll > > >> lower > > >>>> those barriers, and increase the base of people capable of/willing > to > > >>>> contribute. > > >>>> > > >>>> (the cost of submitting a small fix/enhancement right now is too > high > > >> for > > >>>> the casual java developer) > > >>>> > > >>>> -brian > > >>>> > > >>>> --- > > >>>> Brian O'Neill > > >>>> Chief Architect > > >>>> Health Market Science > > >>>> The Science of Better Results > > >>>> 2700 Horizon Drive € King of Prussia, PA € 19406 > > >>>> M: 215.588.6024 € @boneill42 <http://www.twitter.com/boneill42> € > > >>>> healthmarketscience.com > > >>>> > > >>>> This information transmitted in this email message is for the > intended > > >>>> recipient only and may contain confidential and/or privileged > > material. > > >> If > > >>>> you received this email in error and are not the intended recipient, > > or > > >>>> the person responsible to deliver it to the intended recipient, > please > > >>>> contact the sender at the email above and delete this email and any > > >>>> attachments and destroy any copies thereof. Any review, > > retransmission, > > >>>> dissemination, copying or other use of, or taking any action in > > reliance > > >>>> upon, this information by persons or entities other than the > intended > > >>>> recipient is strictly prohibited. > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> On 12/20/13, 3:19 PM, "P. Taylor Goetz" <[email protected]> wrote: > > >>>> > > >>>>> I was hoping not to have to ask this question, since it¹s likely to > > >> start > > >>>>> a heated debate. But here goesŠ > > >>>>> > > >>>>> How would Storm developers feel about switching the build system > from > > >>>>> Leiningen to Maven? > > >>>>> > > >>>>> This has nothing to do with personal preference (I¹m fine with > > >> either). I > > >>>>> ask in the context of release management and integration with the > ASF > > >>>>> infrastructure. > > >>>>> > > >>>>> I know Leiningen is very concise (since it uses clojure) and Maven > is > > >>>>> often looked at as a ³mess of xml². And there are a lot of other > > >>>>> differences that people feel passionate about. So I¹d like to put > > >> ³minor² > > >>>>> differences aside for a minute and focus on a few points that are > > >>>>> important from a release management perspective. > > >>>>> > > >>>>> > > >>>>> 1. ASF infrastructure support > > >>>>> > > >>>>> This is probably the biggest factor. From what I can tell (I could > be > > >>>>> wrong) Storm is the first ASF project to use Clojure and Leiningen, > > so > > >> it > > >>>>> is not well supported from an infrastructure perspective. For > > example, > > >>>>> although there is a Leiningen plugin for Jenkins, it¹s not > installed > > on > > >>>>> builds.apache.org, so we¹d have to ask INFRA to install it which > > could > > >>>>> take a long time. To work around that, the build would have to do a > > >>>>> temporary install of Leiningen with each build. We¹d probably have > to > > >> add > > >>>>> a bunch of support scripts as well to do things like detect test > > >>>>> failures, etc. > > >>>>> > > >>>>> Maven on the other hand is pretty much a first class citizen in > terms > > >> of > > >>>>> ASF infrastructure, and using Maven makes it easy to build/sign > > >> releases, > > >>>>> stage to Sonatype, etc. There are a wealth of plugins as well that > > >>>>> integrate well with infra for such things as publishing docs, > project > > >>>>> websites, etc. > > >>>>> > > >>>>> 2. Developer productivity > > >>>>> One thing lot of people seem to like about Lieningen is the ability > > to > > >>>>> quickly bring up a REPL and start hacking away. For this > experiment, > > I > > >>>>> used to the clojure maven plugin > > >>>>> (https://github.com/talios/clojure-maven-plugin) and found it (for > > >> me) to > > >>>>> be on par with Leiningen. To bring up a REPL you just type: > > >>>>> > > >>>>> `mvn clojure:repl` > > >>>>> > > >>>>> > > >>>>> To do a comparison, I put together a quick and dirty experimental > > >> branch > > >>>>> with Leiningen replaced with Maven: > > >>>>> > > >>>>> https://github.com/ptgoetz/incubator-storm/tree/maven-test > > >>>>> > > >>>>> I¹d encourage anyone to check it out play around to see what > > developing > > >>>>> Storm with Maven would be like. > > >>>>> > > >>>>> > > >>>>> I¹d like to hear opinions from other committers and developers. If > > >>>>> switching to Maven is something we want to do, I¹ll volunteer to do > > the > > >>>>> work. > > >>>>> > > >>>>> Thanks, > > >>>>> > > >>>>> Taylor > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>>> > > >> > > >> > > > > >
