+1 on Karls proposal. 0.8.0 was imperfect, but: 1. we know about the issue 2. have clear step-by-step guide on how to improve (Karl) 3. issue is nit-picky from my point of view
Issue solved. Cheers, Toni On Wed, Nov 23, 2011 at 9:14 PM, Karl Pauls <[email protected]> wrote: > On Wed, Nov 23, 2011 at 8:39 PM, Marcel Offermans > <[email protected]> wrote: > > +1, I think providing such a script is a good way to do it, it makes > checking and building the individual components a lot easier whilst still > maintaining the flexibility of being able to release any subset of > artifacts. I also agree that we should correct the oversight of not > shipping the pom.xml file as part of the source distribution for future > releases. > > Yeah, again, that is just a configuration we have to set so that it > not only generates the -sources.jar but also the -project.{zip,tar.gz} > just like we do at felix. Without that (and there I totally agree with > ant and sebb on this one), it sucks rocks as you have to massage the > stuff quite a bit to get it to work and don't even have the tests, > etc. :-(. > > I think having the -projects plus the two scripts are a good way to go > (technically, its close to releasing the reactor pom - which would be > even easier - but this way, we don't have to tag the trunk). The > script will be simple, just unzip all -projects,cd into each, mvn > clean install, cd out again. That plus the correct list of artifacts > we can give in the vote mail is all that is needed inside the script. > > regards, > > Karl > > > Greetings, Marcel > > > > On Nov 23, 2011, at 14:00 PM, Karl Pauls wrote: > > > >> Hm, after thinking about it for a while, we already have a script for > >> getting the release and verify its checksums etc. -- hence, why don't > >> we provide another one which builds all artifacts as well? > >> > >> This way, we would not need to release the trunk but could still have > >> the individual releases. It would look something like: > >> > >> sh check_staged_release.sh <repo-id> <tmp-dir> # downloads all release > >> artifact from the given staging repo to tmp-dir and verify checksums > >> are present and correct > >> sh build_release_artifacts.sh <ordered-list-of-module-names> > >> <tmp-dir-with-artifacts-downloaded-by-previous-step> # unpack all > >> artifact source distros and build them > >> > >> Obviously, we would provide the missing params in the release vote > >> mail so that all one has to do is to copy'n'past the two lines into > >> the shell (after maybe downloading the two scripts from svn). > >> > >> I think that (together with providing the maven source distributions > >> per artifact which we missed in 0.8.0 ) would make it not that hard to > >> checkout and build and with the source distros one also gets the unit > >> tests which would run during the build (so some level of testing is > >> there as well). > >> > >> How about that? > >> > >> regards, > >> > >> Karl > >> > >> On Wed, Nov 23, 2011 at 10:12 AM, ant elder <[email protected]> > wrote: > >>> Hi, I'm one of the ones over on general@incubator that was commenting > >>> about the 0.8.0 release not being perfect. To avoid all the traffic on > >>> the other lists could we talk about that here? > >>> > >>> I think there was some agreement releases had to have the complete > >>> source in a form that enables development to be done using that > >>> source, there is some doc on this at > >>> http://www.apache.org/dev/release.html#what and also some helpful > >>> commentary in this email > >>> http://apache.markmail.org/message/3odlybipss4wnczl - "we require that > >>> the release include all of the source code for the product (every > >>> component of that product in a format that can be edited for later > >>> maintenance of that product as open source)" > >>> > >>> Also, when doing a release its required that at least three PMC > >>> members review and vote on the release to verify that its good. > >>> There's some commentary on that in this email > >>> http://apache.markmail.org/message/njray5dbazwcdcts - "we require a > >>> person to download the signed source code package, compile it as > >>> provided, and test the resulting executable on their own platform > >>> *before* voting +1 on the release" > >>> > >>> Looking at the 0.8.0 release vote i think that would be difficult to > >>> do because there are so many individual parts, probably too many for > >>> anyone to try to build them all, so i'm guessing no one did and thats > >>> why no one noticed that the source was incomplete. > >>> > >>> > http://mail-archives.apache.org/mod_mbox/incubator-ace-dev/201105.mbox/%3CBANLkTimw_15axkojKwVSVtdHfOPVB_fLEw%40mail.gmail.com%3E > >>> > >>> Other projects when releasing multiple modules like this include one > >>> big source distribution to enable building everything together just > >>> like you do when developing on an SVN trunk checkout. Do you think > >>> there could be one of those for ACE? Or If not and there was another > >>> release like the 0.8.0 one then on the release vote like that what > >>> exactly is it people should do to decide whether or not to vote +1? > >>> > >>> ...ant > >>> > >> > >> > >> > >> -- > >> Karl Pauls > >> [email protected] > >> http://twitter.com/karlpauls > >> http://www.linkedin.com/in/karlpauls > >> https://profiles.google.com/karlpauls > >> > > > > > > > > -- > Karl Pauls > [email protected] > http://twitter.com/karlpauls > http://www.linkedin.com/in/karlpauls > https://profiles.google.com/karlpauls > -- Toni Menzel Source <http://tonimenzel.com>
