ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toni Menzel <t...@okidokiteam.com>
Subject Re: Next release
Date Wed, 23 Nov 2011 22:50:17 GMT
+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 <karlpauls@gmail.com> wrote:

> On Wed, Nov 23, 2011 at 8:39 PM, Marcel Offermans
> <marcel.offermans@luminis.nl> 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 <ant.elder@gmail.com>
> 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
> >> karlpauls@gmail.com
> >> http://twitter.com/karlpauls
> >> http://www.linkedin.com/in/karlpauls
> >> https://profiles.google.com/karlpauls
> >>
> >
> >
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls
>



-- 
Toni Menzel Source <http://tonimenzel.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message