commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@gmail.com>
Subject Re: [VOTE] Release Proxy 1.0 (from rc2)
Date Thu, 21 Feb 2008 18:09:13 GMT
On Thu, Feb 21, 2008 at 5:57 PM, sebb <sebbaz@gmail.com> wrote:
>
> On 21/02/2008, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>  > On Thu, Feb 21, 2008 at 5:27 PM, sebb <sebbaz@gmail.com> wrote:
>  >  >
>  >  > On 21/02/2008, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>  >  >  > On Thu, Feb 21, 2008 at 3:18 PM, James Carman
>  >  >  >  <james@carmanconsulting.com> wrote:
>  >  >  >  > On 2/20/08, Niall Pemberton <niall.pemberton@gmail.com>
wrote:
>  >  >  >  >  > Yup, sorry about this - we changed process just over a
year - I think
>  >  >  >  >  >  following this thread:
>  >  >  >  >  >  http://commons.markmail.org/message/vw3ckyjakjgbdlbu
>  >  >  >  >  >
>  >  >  >  >  >  ...but no-one has go round to updating the docs. The other
part of the
>  >  >  >  >  >  equation is maven2 - its only recently we started using
m2 as the
>  >  >  >  >  >  primary build on some components - before that it was
pretty much all
>  >  >  >  >  >  m1. The few recent m2 component  releases have all be
manual (rather
>  >  >  >  >  >  than using the m2 release plugin - I think JCI used that)
- so I'm not
>  >  >  >  >  >  sure if we have a set procedure - but should document
both options.
>  >  >  >  >
>  >  >  >  >  Well, does anyone have explicit m2 instructions for doing these
>  >  >  >  >  releases (using the profiles in commons-parent, I'd think)?
 I'm
>  >  >  >  >  pretty familiar with m2 as far as day-to-day stuff (clean, test,
>  >  >  >  >  install, etc.), but not for doing releases.
>  >  >  >
>  >  >  >
>  >  >  > How about something like the following:
>  >  >  >
>  >  >  >  1) Tag "proxy-1.0-rc3"  but with the version number set to "1.0"
>  >  >  >  2) Check out the proxy-1.0-rc3
>  >  >  >  3) Build the release artifacts - I think theres a couple of options
here:
>  >  >  >
>  >  >  >  3.1) Run the following maven command:
>  >  >  >  mvn site javadoc:jar source:jar assembly:assembly
>  >  >  >
>  >  >  >  This will create all the artifacts - jars and src and binary distros,
>  >  >  >  but then you need to create checksums and sign
>  >  >  >
>  >  >  >  3.2) Run the following maven command:
>  >  >  >  mvn -Prc -DcreateChecksum=true site install
>  >  >  >
>  >  >  >  This should create all the artifacts installed in your local m2
>  >  >  >  repository, signed and checksums  (note it also creates checksums
for
>  >  >  >  signature files - I delete those)
>  >  >  >
>  >  >  >  4) Upload the artifacts to peopel.apache.org/~jcarman and call a vote
on dev@
>  >  >  >
>  >  >  How about creating a temporary page on the Commons Wiki with this information?
>  >  >
>  >  >  Once the process has been nailed down and tested, it should be moved
>  >  >  to the formal website.
>  >
>  >
>  > Yes, I'll try to find time to do this. The other option is to use the
>  >  maven release plugin - something along the lines:
>  >
>  >   mvn -Prc release:prepare
>  >   mvn -Prc release:perform
>  >
>  >  This has worked OK for me for releasing the poms - but I haven't tried
>  >  it on a component. The main thing I don't like about the release
>  >  plugin is that every time you do release:prepare, it does 3 commits -
>  >  which is alot of noise if you have several release candidates. Also
>  >  I'm not quite sure how we go from stage rc --> actual release. I guess
>  >  you have to tag and version as if it were the proper release - and
>  >  delete the tag if a RC fails.
>  >
>
>  Once the vote has passed, one can just copy the rc tag to the formal
>  release tag.

I don't think this works with the release plugin - which is another
reason for doing it manually - one thing the plugin does is re-name
the scm entries in the pom.xml to reflect the tag.

>  The RC tag should be kept (I guess any failed RC tags could be deleted).
>
>  To help tie this together, it would be an idea to document the RC tag
>  revision that is being voted on. If one wanted to be extra-careful, I
>  guess one could also document the digests of the artifacts as well.

This is not necessary IMO.

Niall

>  >
>  >  Niall
>  >
>  >
>  >  >  >  Niall
>  >  >  >
>  >  >  >
>  >  >  >  >  >
>  >  >  >  >  >  Niall
>  >  >  >  >  >
>  >  >  >  >  >
>  >  >  >  >  >  > >
>  >  >  >  >  >  >  >  Oliver
>  >  >  >  >  >  >  >
>  >  >  >  >  >  >  >
>  >  >  >  >  >  >  >  >
>  >  >  >  >  >  >  >  >>  Oliver
>  >  >  >  >  >  >  >  >>
>  >  >  >  >  >  >  >  >>
>  >  >  >  >  >  >  >  >>  >
>  >  >  >  >  >  >  >  >>  > On Feb 19, 2008 11:31 PM, James
Carman <james@carmanconsulting.com> wrote:
>  >  >  >  >  >  >  >  >>  >> All,
>  >  >  >  >  >  >  >  >>  >>
>  >  >  >  >  >  >  >  >>  >> I have prepared a commons-proxy-1.0-rc2
release candidate.  The
>  >  >  >  >  >  >  >  >>  >> distribution files can
be found at:
>  >  >  >  >  >  >  >  >>  >>
>  >  >  >  >  >  >  >  >>  >> http://people.apache.org/~jcarman/commons-proxy-1.0-rc2/
>  >  >  >  >  >  >  >  >>  >>
>  >  >  >  >  >  >  >  >>  >> and the site can be found
at:
>  >  >  >  >  >  >  >  >>  >>
>  >  >  >  >  >  >  >  >>  >> http://people.apache.org/~jcarman/commons-proxy-1.0-rc2/site
>  >  >  >  >  >  >  >  >>  >>
>  >  >  >  >  >  >  >  >>  >> The SVN tag used to create
the release can be found at:
>  >  >  >  >  >  >  >  >>  >>
>  >  >  >  >  >  >  >  >>  >> http://svn.apache.org/repos/asf/commons/proper/proxy/tags/proxy-1.0-rc2
>  >  >  >  >  >  >  >  >>  >>
>  >  >  >  >  >  >  >  >>  >> All issues brought up thus
far with the first release candidate have
>  >  >  >  >  >  >  >  >>  >> been addressed.  Again,
this is my first release (including signing),
>  >  >  >  >  >  >  >  >>  >> so please review thoroughly
(not that you normally don't).
>  >  >  >  >  >  >  >  >>  >>
>  >  >  >  >  >  >  >  >>  >> Thank you,
>  >  >  >  >  >  >  >  >>  >>
>  >  >  >  >  >  >  >  >>  >> James Carman

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message